Wonderware FactorySuite Terminal Services for InTouch Deployment Guide

(1)

for InTouch™ Deployment Guide

Revision A

Last Revision: September 2002

(2)

the Invensys Systems, Inc. No copyright or patent liability is assumed with respect to the use of the information contained herein. Although every precaution has been taken in the preparation of this documentation, the publisher and the author assume no responsibility for errors or omissions. Neither is any liability assumed for damages resulting from the use of the information contained herein.

The information in this documentation is subject to change without notice and does not represent a commitment on the part of Invensys Systems, Inc. The software described in this documentation is furnished under a license or nondisclosure agreement. This software may be used or copied only in accordance with the terms of these agreements.

33 Commercial Street Foxboro, MA 02035 (949) 727-3200

http://www.wonderware.com Trademarks

All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Invensys Systems, Inc. cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.

Alarm Logger, ActiveFactory, ArchestrA, Avantis, DBDump, DBLoad, DTAnalyst, FactoryFocus, FactoryOffice, FactorySuite, hotlinks, InBatch, InControl, IndustrialRAD, IndustrialSQL Server, InTouch, InTrack, MaintenanceSuite, MuniSuite, QI Analyst, SCADAlarm, SCADASuite, SuiteLink, SuiteVoyager, WindowMaker, WindowViewer, Wonderware, and Wonderware Logger are trademarks of Invensys plc, its subsidiaries and affiliates. All other brands may be trademarks of their respective owners.

(3)

Welcome to Terminal

Services for InTouch

Before You Begin

The Terminal Services for InTouch Deployment Guide is intended to help you efficiently plan, deploy and run InTouch applications on Windows 2000 Terminal Services. As a complement to the Terminal Services for InTouch

User’s Guide, it provides greater detail in architecture design, hardware

selection, and how to leverage the features of Terminal Services in an industrial environment. It specifically addresses the RDP protocol. Additional information on RDP and related protocols are available at the following web-sites:

Document Symbols

This manual uses the following document symbols.

Microsoft http://www.microsoft.com/windows2000/

technologies/terminal/default.asp Automation Control Products

(ACP)

http://www.acpthinclient.com

Citrix Systems http://www.citrix.com

A task to be performed on the terminal server (console) or on the license server.

A task to be performed on the client (local) desktop.

(8)

Must Know Terminology

Checklist: Setting up Terminal Services for

InTouch

Term Description

Console This is the normal desktop experience on the computer that has Terminal Services installed. ICA Independent Computing Architecture. A remote

presentation services protocol from Citrix Systems. RDP Remote Desktop Protocol. The default connection

protocol installed with Windows Terminal Services. Session A log-on instance where 100 percent of the resources

(processing, memory, and hard disk) are managed under a virtual user account, referred to as a session ID.

Terminal Services A service that enables a server-grade computer for multi-user processing and management.

Thin Client (a.k.a. terminal) A device that allows you to send commands to another computer. At a minimum, this usually means a keyboard, a display screen, and some simple circuitry.

Task Reference

Review key Terminal Services for InTouch concepts. Chapter 1 Determine how you want to utilize Terminal Services for

InTouch in your industrial environment.

Chapter 1 Describe how the deployment project meets business

requirements.

Chapter 1 Develop a plan for implementing Terminal Services for

InTouch.

Chapter 2 Review recommended architectures and how to integrate with

the FactorySuite.

Chapter 2 Consider safeguards to minimize the impact of a hardware

failure.

Chapter 2 Identify the right client for the environment and operator

needs.

Chapter 2 Establish guidelines and standards for networking, set-up,

user security, and so on.

Chapter 3

Determine licensing requirements. Chapter 3

(9)

About this Manual

This manual is divided into a series of logical building block chapters that describe the various aspects of using Terminal Services for InTouch. It is written in a "procedural" format that tells you in numbered steps how to perform most functions or tasks.

If you are viewing this manual online, when you see text that is green, click the text to "jump" to the referenced section or chapter. When you jump to another section or chapter and you want to come back to the original section, a "back" option is provided.

Tip These are "tips" that tell you an easier or quicker way to accomplish a function or task.

To familiarize yourself with the WindowMaker development environment and its tools, read Chapter 1, "WindowMaker Program Elements" in your online

InTouch User's Guide. Also, read Chapter 10, "Terminal Services for

InTouch."

For details on the runtime environment (WindowViewer), see your InTouch

Runtime User's Guide.

Online manuals are also included in your FactorySuite software package for all FactorySuite components.

Note You must install the Adobe Acrobat Reader (version 4.0 or later) to view or print the online manuals.

Assumptions

This manual assumes you are:

•

Familiar with the Windows 2000 and/or Windows NT operating system working environment.

•

Knowledgeable of how to use of a mouse, Windows menus, select options, and accessing online Help.

•

Experienced with a programming or macro language. For best results, you should have an understanding of programming concepts such as variables, statements, functions and methods.

Modify applications to run in a multi-user environment. Chapter 3

Test and pilot your system. Chapter 3

Prepare to provide support. Chapter 3

(10)

Technical Support

Wonderware Technical Support offers a variety of support options to answer any questions on Wonderware products and their implementation.

Prior to contacting technical support, please refer to the relevant chapter(s) in your Terminal Services for InTouch Deployment Guide for a possible solution to any problem you may have with your system. If you find it necessary to contact technical support for assistance, please have the following information available:

1. Your software serial number.

2. The version of InTouch you are running.

3. The type and version of the operating system you are using. For example, Microsoft Windows NT Version 4.0 SP5 (or later) workstation.

4. The exact wording of system error messages encountered.

5. Any relevant output listing from the Wonderware Logger, the Microsoft Diagnostic utility (MSD), or any other diagnostic applications.

6. Details of the attempts you made to solve the problem(s) and your results. 7. Details of how to recreate the problem.

8. If known, the Wonderware Technical Support case number assigned to your problem (if this is an on-going problem).

(11)

C H A P T E R 1

Introduction to Terminal

Services for InTouch

This chapter provides you with an introduction to Terminal Services for InTouch. It also presents business and industrial scenarios to help you determine if a server-centric strategy is appropriate for your particular application.

•

Thin computing and Process Visualization

•

Windows 2000 Terminal Services

•

Why Terminal Services for InTouch?

•

Industrial Scenarios

Thin computing and Process Visualization

Windows-based HMI and supervisory control products have empowered operators by making computing easy to use and with better functionality than the traditional mini-computers of yesterday. Now with so many desktops deployed in the business and industrial environments, maintenance and administration have become a major burden on the Information Technology (IT) infrastructure. Accordingly, there is renewing interest in thin computing- a computing model very similar to those mini-computers where the software and processing is performed on a centralized server. New technology in emulation software and browser-based applications now provide this thin computing model to the Windows environment.

Total Cost of Ownership

The use of thin clients promise to reduce the acquisition cost of computer hardware while reducing administrative costs related to systems management. IT managers can then lower their total cost of ownership (TCO) for computer equipment while improving their level of service.

(12)

TCO is a term used to collectively group the benefits associated with thin clients. At a hardware level, thin clients (often called terminals) are devices that rely on a server for applications and data, and perform little or no application processing. They typically have a basic operating system to support a web browser or some form of a terminal emulation software. Thin clients require relatively small amounts of RAM and minimum processing power. In contrast, desktop computers are referred to as fat clients because they run programs locally. Desktop computers usually have more RAM, greater processing power, and large hard-drives to store program files and associated data. Note-worthy benefits of a thin computing model include the following:

•

Centralized deployment of programs. Most (if not all) program execution, data processing, and data storage occur on a server, centralizing the deployment of programs. This ensures that all clients can access current versions of a program. Software is installed only once on the server, rather than every desktop throughout the organization, reducing the costs associated with updating individual computers.

•

Centralized Management. Provides you with the ability to manage centrally while still allowing the individual user the flexibility of using the Windows desktop environment.

•

Increased Security and Reliability. Because no application or user data ever resides on the client, thin computing provides you with more control for security. The use of thin clients can also help prevent the loss of data. Since the data is processed and stored on a server, damage to the client does not lead to destruction of data. This decreases the number of nodes that need to be hardened for data protection.

•

Full advantage of existing hardware. Thin computing extends the model of distributed computing by allowing computers to operate as both thin clients and full-featured personal computers, simultaneously. Computers can continue to be used as they have been within existing networks while also functioning as thin clients capable of accessing server-based programs and applications.

•

Scalability. True scalability means more than adding more clients to your environment. You also need an effective means of managing this

environment as it grows. Thin computing provides the ease of installing new clients, as well as the ease of maintaining them.

Data Access for the Casual User

Another benefit of thin computing is the ability to support a new level of users referred to as casual users. Casual users include maintenance, supervisors, engineers and perhaps vendors who need immediate access to critical

manufacturing or process information that is pertinent to them. They need this information on-demand and for short duration. Internet technology,

telecommunications (voice mail/paging), and wireless Ethernet are typically the preferred mediums to transport such information.

(13)

•

SCADAlarm introduces Wonderware's first mobile client to access and acknowledge factory alarm information from a mobile telephonic device.

•

Terminal Services for InTouch allows you to fully leverage the benefits of Windows 2000 Terminal Services in an industrial environment. With Terminal Services, the processing of InTouch is moved completely off the operator's workstation and onto a centralized server.

•

SuiteVoyager Series introduces the Manufacturing Information Portal that provides Internet access to summary graphics, real-time factory floor data, and reporting information. The Portal has been designed for quick access to summary and analysis information from multiple data sources and from across the enterprise. SuiteVoyager is a fully scalable product, providing process information to hundreds of clients with minimum impact on the control network.

Windows 2000 Terminal Services

Microsoft Windows 2000 Terminal Services is an integral part of Windows 2000 technology that delivers the familiarity and ease-of-use associated with the Windows graphical user interface (GUI) through a thin computing model. Windows 2000 Server or Advanced Server is required to enable Terminal Services.

With the integration of Windows 2000 Terminal Services into the core server operating system, you can now choose to deploy InTouch in a fully server-centric mode, where applications run entirely on the server. Each operator logs on and perceives only their presentation (known as a session), which is transparently managed by the server operating system and is independent of any other client session. Only screen, mouse, and keyboard information is passed between the client and server.

Modes of Operation

(14)

•

Application Server. This is the standard mode for running InTouch. Applications are deployed and managed from a central location. Licensing is required when deploying a Terminal Services-enabled server as an application server. Each client, regardless of the type of operating system and protocol used to connect to Terminal Services, must have a Terminal Services Client Access License (TS CAL), as well as a Windows 2000 Server CAL. Windows 2000 Professional includes one TS CAL, but not a Windows 2000 Server CAL. Access from earlier versions of Microsoft Windows NT, as well as clients using other operating systems, must purchase a TS CAL and Windows 2000 Server CAL.

For more information on Licensing requirements, see "Terminal Services Licensing" in Chapter 3, "Deployment,"

•

Remote Administration. Terminal Services Remote Administration mode allows any server running Windows 2000 Server to be administrated remotely with full access to the built-in administrative tools, as if you were sitting right at the server.

Components

Windows 2000 Terminal Services consists of five components, as described below:

•

Multi-user kernel. The multi-user kernel extensions are fully integrated as a standard part of the Windows 2000 Server family kernel. These are resident on the server at all times, regardless of whether Terminal Services is enabled or not.

•

Remote Desktop Protocol (RDP). This is the default protocol that allows a client to communicate with the terminal server over a network. Independent Computer Architecture (ICA) is another thin client protocol offered by Citrix. Both protocols support several levels of encryption, client-side bitmap caching, and optional compression for low-bandwidth connections.

•

Terminal Services Client. The client software that displays the familiar GUI on a client machine. The client software is a very small software application that establishes and maintains the connection between a client and server running Terminal Services. It transmits all input from the user to the server, such as keystrokes and mouse movements, and all output from the server such as application display information and print streams.

•

Terminal Services Licensing service. This service is required when Terminal Services is enabled for application serving. The service allows Terminal Services to obtain and manage its TS CALs for connecting devices.

•

Terminal Services Administration Tools. Tools consist of software that manages Terminal Services. These include Terminal Services License Manager (if licensing was installed), Terminal Services Client Creator, Terminal Services Configuration, and Terminal Services Manager.

(15)

Why Terminal Services for InTouch?

Terminal Services for InTouch allows InTouch to run in a multi-user environment. For organizations wanting to increase flexibility in process visualization and to control operator workstation management costs, a Terminal Services for InTouch architecture offers an important enhancement to the traditional two or three tier client-server architecture.

Terminal Services for InTouch Benefits

Beyond cost and scalability improvements, Terminal Services for InTouch also provides many technological advantages. For example, you can remotely control an InTouch application for quick troubleshooting and operator training. Using Microsoft's new Terminal Services Advanced Client (TSAC), you can view your process over the web for a super-thin client, full InTouch

experience. You can also provide roaming operators with real-time information and control by using wireless Ethernet.

Lastly, using Terminal Services for InTouch with Embedded NT and Windows CE provides a full desktop experience on hardware that would otherwise be unable to support such operating systems. Embedded clients are generally dedicated purpose devices. Due to InTouch licensing and hardware requirements, full-featured HMI functionality has not been available for embedded-type applications – until now. Terminal Services for InTouch fully supports very thin hardware – hardware with much less components than a desktop computer. Not only are these clients less likely to fail but they can be replaced in less than 60 seconds, reducing the overall MTTR (mean time to repair).

Caution! Terminal Services scalability does not consider the impact on the control network. Data fan out can occur when InTouch sessions exceed the number of topics/update rates that SuiteLink or the I/O devices can support. For a more scalable solution, consider SuiteVoyager.

For more information on the benefits of Terminal Services, see Chapter 10, "Terminal Services for InTouch" in your online InTouch User's Guide.

(16)

Terminal Services and Industrial Applications

In a simple deployment, all InTouch applications will be located on a single computer – a terminal server. This computer also has an I/O server to connect the WindowViewer sessions to the plant process.

Each WindowViewer session may be the same InTouch application or a different one. They can communicate with each other and run as they would in a traditional client-server environment. The primary difference is that now InTouch is operating in a server-centric environment where all the processing is performed on the terminal server. As the architecture expands and more components are added, you need to consider the impact of such an

arrangement.

Knowing if a server-centric environment is appropriate for your application is the first step in the deployment process. Terminal Services requires a fair share of up-front planning and ongoing maintenance. Your existing InTouch applications may need to be modified before running on a terminal server. There must also be greater consideration for fault tolerance and availability as multiple InTouch nodes will be affected if the server goes down.

(17)

There are many benefits to implementing Terminal Services for InTouch, but the degree of benefit will depend on your particular application. Terminal Services for InTouch has a sweet spot for applications that have traditionally been deployed in client-client and client-server environments.

If you have a stand-alone InTouch node and do very little configuration, you will most likely find little value in implementing Terminal Services for InTouch. The benefits tend to also drop as the complexity of InTouch applications increase. Highly complex applications frequently have graphical and distributed I/O requirements that will burden the terminal server and associated network. Due to the protocol nature of Terminal Services, most I/O servers will not work on the client (local) computer.

However, Terminal Services is not an all-or-nothing solution. Industrial applications that do not fit within the scope of a server-centric environment can be left to run on the operator's desktop. For example, if you need an I/O server to be running on the client computer, then keep the I/O server on the operator desktop and only move the InTouch application to the terminal server. This flexibility allows PCs to operate as both thin and fat clients simultaneously.

Business Justification and Project Approval

Many organizations that have made the decision to implement Terminal Services typically explain their decision in terms of business drivers. Although not all organizations focus on the same set of drivers or give them all the same degree of consideration, a well-implemented Terminal Services deployment will often confer benefits upon the user that exceed those planned for during the initial decision-making process.

To help increase your chances for project approval, consider the following points:

(18)

•

Review the capabilities and sample industrial scenarios for Terminal Services for InTouch. Clearly define the scope of the project and stick to it. Knowing what you can accomplish up-front will prevent possible disappointments later in the project life cycle.

•

Consider the initial capital and long-term costs associated with the project. Frequently, initial capital costs are the same for both Terminal Services and traditional installations. True savings are realized as support and maintenance response times are improved.

•

Realize that this is not a desktop deployment. If you have previously configured a domain controller, you have a pretty good idea on the effort that is required to deploy a terminal server. You should, therefore, spend a significant time planning. By understanding the capabilities of Terminal Services and the effort to provide them, you should be able to deliver what you promise.

The first point is perhaps the most important. Implementing Terminal Services to run InTouch will most likely change the role of the operator workstation in your organization. Accordingly, there will be a change in how InTouch and other applications are delivered and supported on the plant floor. A significant success factor for your Terminal Services implementation will be to minimize the changes in how users must work. Although very little change should be necessary for the operator, it will have a much greater impact on the people who support the system. You should have their buy-in before submitting your project proposal.

The bottom line is the Terminal Services for InTouch saves money, effort, and time. By following the points above, you should be able to provide a clear and honest business plan for the executive who will ultimately appropriate the necessary funds. Good Luck!

Industrial Scenarios

The first task in the deployment process is to determine what business and technical issues Terminal Services for InTouch will address. Review the industrial scenarios in this section to familiarize yourself how Terminal Services for InTouch might benefit your organization. The scenarios will be illustrated with a fictitious manufacturing company called MagTape, Inc. Scenarios are presented in italics.

MagTape, Inc. (MTI), was founded in 1981 to manufacture magnetic tape cartridges. The operation involves several processes, each one independently controlled. Some processes use InTouch operator interfaces, while others still use hardwired control panels.

A recent Operations Improvement Strategy now requires greater information to be shared among the operators. This will be accomplished by upgrading the hardwired control panels and providing plant-wide access to process data. MTI's engineering director is particularly concerned about the following issues related to real-time control that may impact the cost and reliability of such a project:

(19)

•

Additional support costs. The cost of maintaining and supporting the

existing operator interfaces has been increasing at an accelerating rate. Computers that will replace the hardwired control panels must be as maintenance-free as possible.

•

Added hardware expenses. To avoid additional costs, a group of spare

Windows 98 computers should be used.

•

Limited access for mobile operators. Certain operators spend most of

their time transporting raw materials throughout the plant. To improve their awareness of process activity, these mobile operators must have access to the same data available in the control rooms.

•

Impact of hardware failures. Hardware failures and their impact on the

process must be minimized. Operator Interfaces must also have the flexibility to take control of a particular area if the local workstation goes down.

At the direction of the CEO, MagTape's engineering director has funded an Infrastructure Renewal Project to determine how these issues could be resolved with minimal impact to MTI's operations and bottom line.

Centralized InTouch Management

By running InTouch applications on a terminal server, only one InTouch runtime program needs to be installed. Service packs, upgrades, and other related maintenance requirements are also done only once – just on the terminal server. All operators are therefore ensured that they are using the current version of InTouch. Accordingly, the costs and challenges of updating workstation machines, especially for remote workstations, are significantly reduced.

MTI can therefore reduce labor costs associated with software maintenance. Only one computer (configured as a terminal server) requires InTouch and its applications to be installed. The new operator interfaces can be Windows-based Terminals or other thin client computers.

(20)

Beyond viewing the process, MTI can also remotely modify applications. They simply need to connect to the terminal server launch WindowMaker. The task of maintaining the same application version among different repositories is no longer necessary.

WindowMaker does not currently support multiple users. Only one person may edit an application at any one time. If another person concurrently launches WindowMaker for the same application, it may become corrupt and/or unpredictable machine operation may result.

Reduced Hardware Costs

Terminal Services Clients run on the following platforms:

•

Windows CE-Based Terminals

•

Windows for Workgroups 3.11

•

Windows 95

•

Windows 98

•

Windows NT 3.51 or later.

•

Windows 2000

Note Adding Citrix MetaFrame™ and/or ACP ThinManager™ increases the available client types to non-Windows-based workstations, including UNIX, Linux, and industrial display panels. Consult the associated vendor to verify Wonderware support for a particular non-Windows-based operating system. With the integration of InTouch and Terminal Services, you can deploy the latest applications in a fully server-centric mode. By removing the processing and data storage tasks from the client machine, you can greatly extend the life of your existing hardware. In some cases, the need to replace may not occur until the computer physically breaks down.

Terminal Services for InTouch and 3rd party industrial panel displays can also provide an economical alternative for process visualization in harsh

environments. The increased cooling requirements and stronger construction typically make industrial panel displays more expensive than their desktop counterparts. With Terminal Services, industrial hardware costs are reduced because you no longer need high-powered processors, extra memory, floppy or CD-ROM drives. Many industrial panel displays now provide the ability to boot and connect to a terminal server from ROM, and therefore, do not require the added expense of a hard drive. No moving parts also extends the life of hardware because MTBF (mean-time-between-failure) is improved.

MTI can therefore experience the new features of FactorySuite and Windows 2000 with their existing Windows 98 computers. If MTI requires more robust hardware to replace the control panels, they can install industrial-grade computers. These machines only require the minimum components to run the emulation software, and therefore, can be purchased at a significantly reduced price.

(21)

Remote Access

Operators and other end-users gain access to a terminal server over any Transmission Control Protocol/Internet Protocol (TCP/IP) connection including Remote Access, Ethernet, the Internet, wireless, wide area network (WAN), or virtual private network (VPN). Due to the reduced bandwidth requirements of the RDP/ICA protocol, Terminal Services extend the capabilities of InTouch to users who would otherwise be unable to access the FactorySuite.

Wireless networks have traditionally been unable to support the large amount of process information for real-time monitoring and control. With Terminal Services for InTouch, applications can run with the same response time and performance as their counterparts directly connected to the local area network (LAN).

MTI can therefore support real-time monitoring and control for their mobile operators. The client terminals need only the emulation software to connect to the terminal server. They can then simply launch WindowViewer to monitor the operation of choice.

(22)

Internet Access

Using Microsoft's new Terminal Services Advanced Client (TSAC), remote users can access a terminal server over the Internet. TSAC is based on the RDP 5.0 feature set, but comes in the form of an ActiveX control. The ActiveX control can be downloaded and executed within Microsoft Internet Explorer (I.E 5.0), allowing remote users to experience full InTouch with super-thin clients. Microsoft Point-to-Point Tunneling Protocol (PPTP) provides secure access to a private network for users operating over a public medium, such as the Internet.

MTI can therefore support real-time monitoring and control for their mobile operators with either the Terminal Services Client software or by simply launching a web browser and downloading the TSAC ActiveX control.

(23)

Increased Availability

Network Load Balancing Services is a feature of Windows 2000 Advanced Server that enhances the availability and scalability of applications. It provides constant support to end-users by redirecting the connection from a failing or offline server to a backup. After necessary maintenance is completed, the offline computer can transparently rejoin the cluster.

Remote Control is a feature of Terminal Services that provides the ability to take control of another workstation in the event of a client hardware failure. Remote Control also provides an easy way to train operators and monitor operations without being physically next to the terminal.

MTI can therefore be confident that even though failures may occur, their impact on production will be a minimum. Remote Control enables a workstation to immediately take over another that has failed. By adding a second server and installing Network Load Balancing, all the sessions are protected.

Wonderware strongly recommends that you consult a Microsoft professional and perform adequate testing before deploying load balancing into production. ACP ThinManager 2.3 or later supports server fail-over for both Windows 2000 Server and Advanced Server.

(24)

(25)

C H A P T E R 2

Project Planning

This chapter provides you with a planning model to properly deploy Terminal Services for InTouch. It also provides architecture guidelines for running applications on a LAN/WAN network and how to integrate with the FactorySuite and third party software.

•

Deployment Planning Model

•

Identifying Key Team Members

•

Defining Vision and Scope

•

Assessing Risk

•

Documenting Your "As-Is" Environment

•

Creating a Functional Specification "To-Be"

•

Creating/Approving the Physical Design

•

Building the Master Project Plan

Deployment Planning Model

Terminal Services for InTouch requires a fair share of up-front planning. The important thing to remember is that this is not a desktop deployment. If you have ever installed a domain controller, you have a pretty good idea of the effort involved.

You should follow Microsoft's Solutions Framework deployment-planning model for designing and implementing Terminal Services for InTouch. The following flowchart offers a simplified view of the approach. It highlights the major activities and tasks and their associated milestones and key deliverables that are important for the entire project team.

Although the activities leading to each milestone have a logical progression, they need not take place in the order stated. Different team members can perform activities concurrently, to leverage resources of people, time, and money. Use your best judgement and knowledge of the application to deciding the optimal time to work on any specific activity. To maximize project efficiency, however, you should not change the sequence in which the four

(26)

The roadmap provides a high-level overview of the deployment process. It includes:

•

Activities that are necessary to complete the project deliverables and advance to the next milestone.

•

Resources that are necessary to complete each activity and create project deliverables.

•

Deliverables resulting from activities that are necessary to complete a timely and effective project.

Use this roadmap to gain a comprehensive visual perspective of how your team must prepare itself to undertake this project. Gray highlighted areas in the left column denote the four milestones, and are explained below.

For more information on the Microsoft Solutions Framework deployment-planning model and sample documents, refer to the Microsoft's Resource kit for Windows 2000.

A Note About Documentation

Just like electricians who deliver electrical wiring diagrams at the end of a job, you should provide reference material upon completion of this deployment. The roadmap contains many documents, but none are as important as the ones needed for the support professional who may need to rebuild a machine or make minor modifications. Documenting vendor profiles, network topology, computer setup, security settings, program configurations, and so on, are key deliverables for a complete project. Don't forget the supporting

(27)

(28)

Milestone Deliverable Activity Vision/scope

approved (Envisioning phase)

Vision/scope document The vision statement provides a conceptual foundation for the entire project. The project scope defines specific parameters and features of project implementation. An opportunity cost analysis is conducted.

Risk management plan This plan provides a high-level view of risks that could occur throughout the project with parallel mitigation plans. The risk management plan is revisited during each of the succeeding phases and milestones. Bugs and issues database This database is a repository in which all issues that

arise during the project are logged and resolved. The bugs and issues database is revisited during each of the succeeding phases and milestones.

Project plan approved (Planning phase)

Functional specification This specification identifies business and technical design requirements, including any proposed products and technologies. The functional specification describes specific project deliverables and the final release product.

Physical Design This document details the work that will take place. It is a compromise between the goals of the project and the constraints of technology, finance, and time. Master project plan This plan provides the essential elements needed to

implement and track the actual project and describes the project from business, technical, application, and implementation perspectives, including all tasks needed to complete testing and piloting.

Master project schedule The schedule provides the essential elements needed to track time-sensitive deliverables.

Scope

complete/first use

(Developing phase)

Pilot server The goal is to test terminal server and InTouch applications in a controlled environment, but engaged in real-world activity. This involves building a test lab, identifying a Pilot Group, and documenting use cases. Postmortem The pilot deployment concludes with a meeting to

(29)

Identifying Key Team Members

Terminal Services for InTouch will change the role of the client desktop in your organization. A successful implementation starts with building a team with people who have the right expertise for the job, who are empowered to use their expertise, and who are held accountable for results in their areas of responsibility. The team should include a mixture of people who can promote buy-in and maintain continuity throughout the deployment.

Seven distinct roles must be filled and are outlined in the table below. There need not be a one-one relationship for each role.

Release (Stabilizing/ Deploying Phase) Server deployed throughout the environment

For the most part, the full deployment process

resembles the pilot deployment process, but on a larger scale. Operators and support staff should be trained at this time.

Deployment assessment During and after the deployment, communicate with the project overseers to report progress and gauge overall satisfaction. The result of a successful

deployment will be a satisfied customer or management unit, the satisfactory achievement of all primary deployment goals, and a process visualization infrastructure that can be adequately maintained and scaled for the future.

A stable, scalable process visualization infrastructure

Keep the test lab running after the deployment to test new applications and any significant changes you want to make to the server or network

Team Member Rule Skill Set

Executive Sponsor Provide leadership, money and human resources

Assure changes are adopted into the company culture from the top down

Familiarity with the FactorySuite and Terminal Services

Understanding of business drivers

Project Manager Drives critical schedule decisions Familiarity with the FactorySuite and Terminal Services

Familiarity with project management tools

System Integrator Represents the engineers who will be designing and installing the system

Experience in FactorySuite components and how to apply them in a Terminal Services environment

Experience in Microsoft operating systems, and networking technology

(30)

Defining Vision and Scope

The vision statement is an expansive view of the proposed deployment. It describes the top business reasons for deployment and broadly defines the overall results of successful completion.

For more information on how MTI used business drivers to justify Terminal Services for InTouch, see "Industrial Scenarios" in Chapter 1, "Introduction to Terminal Services for InTouch,"

Scope defines the portions of a vision that can actually be accomplished within the project constraints. The project scope provides boundaries for the vision statement by specific details that include business reasons for deployment, features, resources, and schedule framework. By understanding the capabilities of Terminal Services and the effort to provide them, you should be able to deliver what you promise.

Testing and Validation

Ensures all issues are known before deployment

Performs scalability analysis and performance testing

Familiarity with applications and operating systems

Familiarity with the process and related operations

Logistics Management

Ensures a smooth rollout of product or service

Familiarity with the organization's system and network infrastructure

Good relationship with the system integrator and vendors

Good understanding of the delivery schedule

Training Helps identify and meet end-user needs and desires

Good understanding of the FactorySuite and Terminal Services

Ability to write clear and useful technical documentation

Experience training users End-user Represents the operator and

people responsible for maintaining the system

Good understanding of the operations Good relationship with the operators, maintenance and management

(31)

The scoping process should be S-M-A-R-T: Specific, Measurable, Achievable, Result-based, and Time-oriented. The table below provides a more detailed definition of S-M-A-R-T.

Assessing Risk

Risk identification and ranking is the first step in the proactive risk

management process. It provides the team with information it needs to bring major risks to the surface before they adversely affect the project.

Possible risks in deploying Terminal Services for InTouch are:

•

Not testing sufficiently, or not allotting enough time for testing.

•

Failing to account for the behavior and interaction of existing programs that may not be multi-user compliant.

•

Failing to accurately determine the scalability of current and future applications.

•

Failing to understand end-user expectations.

•

Not providing adequate security to protect system files and applications.

•

Failing to adequately train personnel who are responsible for maintaining the system.

Risk is composed of two factors: probability and impact. Risk probability is the likelihood that an event will actually occur. Risk impact is the severity of adverse effects on operations, safety, cost, or the ability to continue with the project. Once identified, the risk is rated (e.g., high, medium, or low) based on its probably and impact, and a corresponding mitigation plan developed. The assessment is then entered into a risk assessment matrix. This matrix should be a living document, updated whenever there is a change, and included in deployment status reports.

Action Definition

Specific Specifying results to be achieved (for example, what action will be taken or what application will be deployed).

Measurable Clearly specifying what will be achieved (for example, the number of seats deployed or the number of business units completed).

Achievable Identifying what the enterprise will achieve by this action (for example, plant-wide access to process data).

Results-based Establishing realistic outcomes based on company resources and project parameters.

Time-oriented Setting a realistic time frame to achieve specific goals (for example, will commence on X date and complete on Y date).

(32)

Sample Risk Matrix

Documenting Your "As-Is" Environment

Before beginning the deployment process, it's a good idea to survey the existing infrastructure to create a baseline for improvement and help you determine how the new technology will fit in. This is especially important if you are migrating existing InTouch applications to a terminal server.

Terminal Services for InTouch will change the role of the operator interface in your organization. This will come a change in how InTouch applications are delivered to the operator, how they are used, and how they are maintained. These changes in process are known as Business Process Redesign (BPR). An important point with BPR and your terminal server deployment is minimizing the change in how the operators must work, and their ability to perform day-to-day functions.

A starting point for BPR is determining what your process visualization capabilities and requirements are today. This is known as the as-is model. When documenting your "as-is" model, include both technical information and operator interface requirements. By documenting the existing technical environment, the team can make a more educated decision on the ability of the system to support the deployment, and what additional hardware/software may be necessary.

Documenting LAN Information

The local area network (LAN) has become a popular control network. A LAN is almost always confined to a single plant.

Even though the low bandwidth requirements for RDP and ICA will place a relatively insignificant burden on the infrastructure, you will want to ensure all identified users are able to connect to the terminal server. Understanding the data flow patterns for the applications that you will be putting on the terminal server, their required resources, and the network path they travel will help determine if any modification is necessary.

Impact Probability Risk Description Owner Date Mitigation High High Some of the existing

applications were not designed to operate within a Terminal Services environment.

Testing mm/dd Testing will need to profile the various applications to determine whether or not they are compliant.

High Low Routers are configured to filter port 3389.

Project Manager

mm/dd Configure routers to allow connections through port. Medium Low May not be able to use

existing Windows 98 computers.

System Integrator

mm/dd Evaluate available protocols and match with hardware requirements.

(33)

Terminal Services supports only TCP/IP connections between the TS client and server. If other protocols are in use, such as IPX or NetBEUI, you must add TCP/IP. You will still be able to IPX or NetBEUI as the transport protocol for non-terminal server traffic, such as network file or printer sharing.

Documenting WAN Information

A wide area network (WAN) is the interconnection of geographically dispersed buildings extending beyond a single area. By deploying TS clients at remote office locations and only sending the RDP or ICA traffic across the wide area, you can realize the same bandwidth savings as in the LAN. If the WAN consists of frame relay connections, distinguish between committed rates and burst rates.

Determine if filters have been implemented on the routers or firewalls that may prevent clients from remotely gaining access to terminal server. Check to make sure that the RDP port (port 3389) is not blocked at the firewall and that access to the specific corporate segments is not limited to certain Internet Protocol (IP) or Internet work Packet Exchange (IPX) network addresses. If these blocks are in place and they prevent remote connections, the team must address them during deployment.

Documenting Internet Information

The new Terminal Services Advanced Client (TSAC) enables remote users to access a terminal server over the Internet. The main difference between Internet and other networks is security implications.

If your organization uses a firewall, determine if it is a packet-level or an application-level firewall. Packet-level firewalls are easier to configure for new protocols. If an application-level is used, check with your Internet Service provider (ISP) if they can define a filter for the RDP protocol.

Document the method the network uses to connect to the Internet. This will help you determine how much bandwidth is available to terminal server. Depending on the frequency remote users will access a terminal server, your team should know the costs and availability of a permanent connection to the Internet.

Documenting the Operator Interface

No matter how powerful and robust your server is, or how well you have designed your environment, in the end the success of your project will be measured by the usability of the client. Knowing the needs of the end-user and the environment where the operator interface will be located is critical to a successful project.

In order to set the expectations of the users, you will need to be able to measure what they have and use today with what you intend to deliver. These

measurements are known as benchmarks. Benchmarks are used to draw comparisons between the "as-is" and the "to-be" models and highlight areas where expectations can be exceeded, can be met, or are deficient.

(34)

•

Access to programs other than InTouch

•

Time delays to process information or query databases

•

Size and quality of video displays

•

Special interface requirements such as touch screens, keyboards, or sound

•

Access to a disk drive

•

Local printing

•

Environmental hazards

•

User security – permissions and rights

You also need to identify any I/O devices that are connected to the operator interface. Generally, I/O devices local to the client computer are not supported. The exception is a low throughput device at the client (such as a hand scanner or low bandwidth serial device). Using the client for demanding I/O devices can have a negative impact on the InTouch application. Connecting all of the I/O to the server solves this problem, but it may not be practical, especially if your terminal server system is replacing a system that used distributed

computers to collect and update data points around the plant.

There are two options if I/O devices cannot be moved to the terminal server: 1. Use a desktop replacement where only the InTouch application is moved

to the terminal server. The I/O server remains on the local computer and runs as normal.

2. Use an ACP Enabled Thin Client. These clients support special drivers including high-speed serial, Profibus, ControlNet, and DeviceNet. For more information on ACP Enabled Thin Clients, see the ACP documentation at http://www.acpthinclient.com.

Finally, document system security and user profiles. You will most likely add more security on the terminal server, but operators should not perceive any loss in permissions or rights. Keeping familiar procedures and practices is the key to minimizing BPR.

Documenting Logical Design

Logical design is a high-level understanding of the business and operational requirements without considering the technology used to achieve them. It describes what events occur when an operator or process performs some action. Most often, there is no correspondence between the logical architecture and the physical topology of the system.

The purpose of documenting the current logical design is to express any business requirements that must remain when migrating to a server-centric environment. The system integrator then has the responsibility to develop a physical design that attempts to meet each business requirement (existing and proposed) while applying the constraints of technology, finance, and time.

(35)

Creating a Functional Specification "To-Be"

The functional specification is the next step after documenting the environment. It is a high-level explanation of how Terminal Services for InTouch will be designed and what it will do. The functional specification should be considered a blueprint for the deployment process and presents goals that have been agreed by all team members. However, the team should not treat the functional specification as something written in stone. It should be a living document that the team updates regularly to reflect changes in scope or schedule.

The functional specification should ensure that what the team wants to achieve is what is required by the business. When you can directly relate the outcome of the deployment process to business goals, you have your to-be model. The "to-be" model is a set of target measures that you will work to achieve. Most measures will be quantifiable, like the number of seconds to launch InTouch, while others will be more subjective, such as operator satisfaction as a result of improved stability. The "to-be" data collection will most often come from your pilot users. By comparing this data against the benchmarks, you can determine whether you are ready to proceed with your implementation.

Creating/Approving the Physical Design

A physical design is part of the design process in which you collect the information you have gathered about the current state and the goals that have been identified, and use this information to develop a plan for deploying Terminal Services for InTouch within the limits set forth in the vision/scope document.

The physical design builds upon the logical design and functional specification by applying real-world technology constraints, including any implementation and performance considerations. It is a compromise between the needs of your business and the limitations of the computer. This is also the point at which the team can estimate human resources, costs, and schedules.

(36)

Choosing a Domain Setup

The first part of developing the physical design involves planning the position of Terminal Services within your enterprise. Terminal Services need not be on a Windows 2000 domain to function. Without a domain, however, users must have separate accounts on every terminal server. This limits scalability and makes it more difficult to administer groups of users. Industrial organizations without many users can typically use a single domain.

For more information on setting up Windows 2000 Server domains, see your Windows 2000 documentation

Note If you add Terminal Services to a domain that uses DHCP, keep the client IP addresses fixed. WWLogger, SuiteLink and Network Load Balancing all rely on permanently assigned IP addresses to identify clients.

Install Terminal Services as a stand-alone server. We strongly recommend that you not run Terminal Services on any computer that also acts as a database server (such as IndustrialSQL Server), RAS server, PPTP server, or domain controller. Terminal Services is designed to perform like Windows 2000 Professional at the end-user level, and it will not assign top priority to critical domain-level processes. Installing Terminal Services on any of these servers can significantly degrade performance.

(37)

The location of the terminal server will mostly depend on how information flows from the plant floor. Unlike the traditional client-server relationship in which the desktop client is communicating directly with the I/O servers and databases, terminal server creates an indirect communication path from the client to the terminal server and then to the destination server. This is

demonstrated below, which depicts the data flow and bandwidth requirements between the TS clients and terminal server.

IndustrialSQL Server and the I/O servers are no longer in direct

communication with the clients. Instead, clients communicate with them only through the terminal server. This way, the high bandwidth requirement exists only between the terminal server and the other servers. The bandwidth requirements between the clients and terminal server are much lower. The RDP and ICA protocols offer similar performance, and on average have a utilization of approximately 20Kbps per user session.

(38)

Expanding to the WAN

By deploying TS clients at remote locations and only sending the RDP or ICA traffic across the wide area, you can realize the same bandwidth savings as on a LAN. The functional difference between a WAN and LAN is that the WAN requires switches to route information to the destination. The figure below illustrates the best use of such a network.

Only the RDP and ICA traffic traverses the wide area connections. All the bandwidth-intensive processing requirements are located at the same physical location as the high-speed switching backbone. The information you gathered while documenting your "as-is" environment is now very critical to

understanding bandwidth requirements, latency issues, and data flow requirements.

Note Printing considerations are important! When assessing Terminal Services across a WAN (and to some extent a LAN), you need to pay particular attention to the location of printers and how clients have been configured to access them.

If an operator prints to a local printer that resides on the operator's LAN but across a slow link from the server running Terminal Services itself, the print job is spooled across the slow link to the printer. This adds to the bandwidth requirements for Terminal Services because the network is required to handle print traffic as well as keystrokes, mouse events, and screen updates.

(39)

Choosing a License Server

The Terminal Services Licensing service is a separate entity from Terminal Services. In most large systems, the license server will be deployed on a separate server although it can be co-resident on the terminal server in some smaller systems. Regardless of where it resides, Licensing is a low-impact service. It requires very little CPU or memory for regular operations, and its hard disk requirements are small, even for a significant number of clients. The license server must be discoverable by the terminal servers. For a Windows 2000 domain, this means the license server must be deployed on a domain controller. The terminal server will discover the license server by enumerating its domain controllers and checking for Terminal Services Licensing.

It is also possible to deploy a license server in a Windows 2000 network on a site basis. This approach, known as the enterprise-licensing configuration, can be selected at installation. It will allow any terminal server in the same physical site to discover the Licensing service, even across domain boundaries. This configuration does not support discovery from remote sites within the network.

Note In determining the location of a license server, discoverability is the most critical factor. A domain, site or workgroup hosting terminal servers must also host a license server. For critical applications, there should be at least two discoverable license servers to ensure high availability.

Once a terminal server has discovered a license server it will continue to use that as long as it is available. The terminal server will communicate with its default license server about once an hour to assure it is still present. If it cannot

(40)

Note Terminal Services Licensing only runs on Windows 2000 Servers, and only manages licenses for Windows 2000 Terminal Services.

Integrating with the FactorySuite

Terminal Services for InTouch is the only Wonderware product currently supported on a terminal server. Other components of the FactorySuite must be installed on a separate computer. The following describes limitations you will encounter when integrating Wonderware products with Terminal Services for InTouch:

NetDDE is limited to console (server) use only, because of the

\\node\application|topic!item naming convention. Since several sessions share

the same node, NetDDE cannot differentiate between sessions. A client will not connect, even if it is the first user to connect to NetDDE.

If DDE is selected for a particular Access Name, SuiteLink will be used. This will impact the ability to communicate to certain I/O servers and Microsoft Office products (such as Excel) that depend solely on DDE. For these situations, a tagname server can be used. A tagname server is an application that contains only InTouch QuickScripts and tagnames. By running it on the console or separate machine, you now have the ability to communicate using both DDE and SuiteLink.

An instance of WindowViewer running on the terminal server acts as a tagname server. The tagname server uses NetDDE to communicate to the I/O

(41)

For more information on how to configure a tagname server, see "Creating a Tagname Server Application" section of the InTouch User's Guide.

Note The diagram above shows a common network for both the clients and normal data traffic. Based on the "as-is" LAN analysis, you may need to separate the networks or install switched hubs to provide adequate bandwidth. SPC Pro, InTrack, and InBatch are currently not supported. However, you can still access data using any database query tool or ActiveX control.

AlarmSuite Logger must be disabled on the terminal server. AlarmSuite does not support multi-user configuration. You must use a tagname server on a separate computer to log alarms to the database. However, you can use AlarmSuite ActiveX controls in the WindowViewer sessions to query and display alarms.

I/O servers must be Windows 2000 Server Ready to run on a terminal server. They must run on the console and not as a session. All other I/O servers must be installed on a separate computer as shown above.

IndustrialSQL Server cannot import tagnames from InTouch running as a session. IndustrialSQL Server accepts only one Tagname.x database from each node. Use a tagname server to aggregate the tags you want stored and import these tags. The tagname server may run on the terminal server console or on a separate computer.

(42)

The terminal server acts as an application server, running the WindowViewer sessions. A separate computer acts as a data server, running IndustrialSQL Server, I/O servers, and if necessary, a tagname server. In this situation, you need a tagname server to import Memory or System tagnames to

IndustrialSQL Server.

Note The diagram above shows a common network for both the clients and normal data traffic. Based on the "as-is" LAN analysis, you may need to separate the networks or install switched hubs to provide adequate bandwidth.

Choosing the Right Client

Available client computers range from desktop replacements to industrial display panels. They all connect to terminal server using a small client program installed on disk or in firmware. The choice of which client platform to use depends on the currently installed base and operator interface needs.

Your client computer must be able to communicate to terminal server using the RDP or ICA protocol. ACP Enabled Thin Clients embed a version of ICA. A feature comparison among the three options is shown below:

Note The column marked ACP+ICA means that both ACP ThinManager and Citrix MetaFrame (ICA) are installed on the terminal server.

Feature Description RDP ICA ACP+ICA

Clients 32-bit client for Windows based PCs (Windows 95, Windows 98, Windows NT

Workstation/Server 3.51, Windows NT Workstation/Server 4.0, Windows 2000 Professional/Server)

x x _N/A1

16-bit client for Windows for Workgroups 3.11 x x N/A 16-bit client for older versions of Windows and

the MS-DOS operating systems

x N/A

Windows CE-based client (Windows-based

Terminal Standard and H/PC Pro) x

2 _x _N/A

UNIX client, Macintosh client, Java client x N/A

Browser client _x8 _x _x10

Thin client enabling for x86 based PC platforms _x14 Transport

Protocols

TCP/IP x x x

SPX, IPX, NetBEUI, and Direct Asynch x

Network connections

Connect client over local area network (LAN) x x x Connect client over wide area network (WAN) x x _x11

(43)

Audio System beeps x x x Support for stereo Windows Audio (system and

user)

x _x12

Local Printing Printing to a local printer attached to a PC client x x N/A Printing to a local printer attached to a WBT x x N/A Printing to a local printer attached to a thin client x x x Local Drive

Mapping

Local drives accessible from server-based

applications x

4/7 _x _x13

Local I/O Redirection of server COM ports (COM port

remapping) x

3 _x _x

High speed serial transfer module (up to 115 KBps)

x Touch screen support out of the box (Elo and

MicroTouch)

x

Profibus module x

DeviceNet module x

ControlNet module x

Cut and Paste Cut and paste of text/graphics between client and server

x x x

Cut and paste of files/directories between client

and server x

4 User-centric

session access

Client remembers previous user's logon name for each connection

x Connect to an active or disconnected session using a different screen resolution than the original session

x

Connect directly to an application (InTouch) rather than an entire desktop

x x x

Server-based applications resize and minimize on a Windows PC similar to local applications

x N/A

Application Publishing

Advertise server-based applications directly to client desktops

x x

Load Balancing

Pooling of servers behind a single server address

and for increased availability x

5 _x5,6 _x5,6 Failover Client connects to alternative terminal server if

its terminal server fails X

5 _x5,6 _x

Automatic failover without operator intervention x Remote

Control

Viewing and interaction with other sessions x x x Bitmap

Caching

Optionally cache display bitmaps to disk for improved performance

x x N/A

Wonderware FactorySuite Terminal Services for InTouch Deployment Guide

for InTouch™ Deployment Guide

Contents

Welcome to Terminal Services for InTouch ...7

CHAPTER 1: Introduction to Terminal Services

for InTouch...11

CHAPTER 2: Project Planning ...25

CHAPTER 3: Deployment ...47

Welcome to Terminal

Services for InTouch

Before You Begin

Document Symbols

Must Know Terminology

Checklist: Setting up Terminal Services for

InTouch

About this Manual

Assumptions

•

•

•

Technical Support

C H A P T E R 1

Introduction to Terminal

Services for InTouch

Contents

•

•

•

•

Thin computing and Process Visualization

Total Cost of Ownership

•

•

•

•

•

Data Access for the Casual User

•

•

•

Windows 2000 Terminal Services

Modes of Operation

•

•

Components

•

•

•

•

•

Why Terminal Services for InTouch?

Terminal Services for InTouch Benefits

Terminal Services and Industrial Applications

Business Justification and Project Approval

•

•

•

Industrial Scenarios

•

•

•

•

Centralized InTouch Management

Reduced Hardware Costs

•

•

•

•

•

•

Remote Access

Internet Access

Increased Availability

C H A P T E R 2

Project Planning

Contents

•

•

•

•