FactoryLink 7 2 Technical Overview Rev2

How can FactoryLink help you? FactoryLink provides visibility into the entire process, giving the right

information to the right people when they need it. A graphical user interface lets operators monitor and control pumps, tanks,

valves, motors, switches, and other key process equipment. An alarm system alerts operators to problems and keeps a history for later

analysis. Real-time and historical trend charts help operators and managers improve

efficiency and resolve problems. Reports and historical data help satisfy management and regulatory

requirements. FactoryLink supports both local and remote monitoring to provide secure

access to critical information at the plant or even at a manager’s home. FactoryLink connects RTUs, programmable controllers, production and test

equipment, business systems, and other supporting systems via OPC, XML, proprietary, or custom protocols, providing unparalleled connectivity.

A rich set of artwork, developed specifically for industrial automation systems and equipment, is included to ease the configuration process.

Tecnomatix keeps up with the right software technology changes, so you don’t have to.

FactoryLink® 7.2 Technical Overview (Preliminary) Introduction FactoryLink software is used by customers in many industries. The one thing these customers have in commonwhether they make steel in Mexico, build cars in Detroit, make candies in Argentina, brew beer in St. Louis, or manufacture electronics in Koreais that they need more knowledge about their processes in order to cut costs, improve quality, and stay competitive. In today’s global economy, knowledge has never been more important. Process Knowledge and Control FactoryLink® software provides the process knowledge and control needed to perfect the products companies make and the processes they manage. FactoryLink monitors, supervises, and controls processes in a variety of industries around the world. FactoryLink is highly scalable and can be used to build from the simplest Human-Machine Interface (HMI) systems to the most complex and demanding Supervisory Control and Data Acquisition (SCADA) systems. The new FactoryLink 7.2 software release leverages the features introduced in version 7.1 and adds new features to provide enhanced ease-of-use in implementing standalone, distributed, and redundant systems. FactoryLink allows data to be collected from a variety of plant floor devices and valuable information to be distributed easily throughout the entire organization. Tecnomatix is a leading supplier of industrial automation software solutions, with over 80,000 seats of FactoryLink installed in more than 60 countries worldwide.

Based on Open Standards Microsoft Windows XP Microsoft Windows 2000 Windows Terminal Services

support for remote access by thin clients

OPC ActiveX ODBC C++ Microsoft Visual Basic for

Applications (included) Microsoft SQL Server 2000

(included) Microsoft .NET

FactoryLink 7.2 Technical Overview of 30

System Architecture FactoryLink Internal Architecture FactoryLink’s internal architecture is based on the Tecnomatix Open Software Bus architecture. The patented design of industry’s only Open Software Bus (U.S. Patent # 4,908,746) is a key factor in the success of the FactoryLink product line. Highlights of the Open Software Bus architecture are: The Open Software Bus provides a global, real-time database. All tasks (programs) have access to all real-time data. Exception processing is performed by the real-time database. High-speed, bi-directional block transfers between tasks and the real-time database assure maximum speed

and performance. Tasks communicate through the bus in real time using tags (sometimes referred to as elements or variables). Tasks can be added or removed without affecting other tasks. The architecture is extensible and completely open. Custom tasks developed with the Programmer’s Access Kit (PAK) can be “plugged in” just like

Tecnomatix-developed tasks. The RAM-resident, real-time database supports tags with the following data types:

o Digital o Analog o Long Analog o Floating Point o Text Messages

Tasks access and process changes only when needed, significantly improving speed and performance. Exception processing eliminates unnecessary activity by the computer and on networks. The architecture provides a flexible development platform for a wide variety of applications.

6
U.S. Patent # 4,908,74
11/11/2003


FactoryLink Distributed Architecture The fundamental architecture of FactoryLink is based on the latest Microsoft Windows technology and three-tier model of distributed client/server processing. In this model, there is a clear separation between client services, business services, and data services, which facilitates the efficient design of applications. Connectivity between clients and servers is provided via LAN, WAN, dial-up connection, or through the Internet. Systems can even be set up to allow remote users to access the system on their pocket PCs through Windows Terminal Services, so they are always aware of the latest information. Application servers are responsible for all data processing. Client Services Tier - The client services tier, also known as the user interface, is positioned closest to the user. In FactoryLink, the client services tier consists of the graphical user interface for operators and/or developers. If a client connects to multiple servers, information is displayed as if it were coming from a single server. Business Services Tier - The business services tier processes data and provides information to the client services tier. In FactoryLink, the business services tier consists of the FactoryLink server that supports the collection, processing, and logging of data. The FactoryLink server includes application configuration data, run-time tasks, and a real-time database. Data Services Tier - The data services tier stores and manages an organization’s historical data. In FactoryStandard Edition Microsoft SQL Server 2000 database (shipped storage functionality and management of historical data. Factoras well as provides native interfaces to Oracle and Sybase. Centralized Application Development and Maintenance FactoryLink applications are stored on the FactoryLink server, bclient in the system with a development license. Any applicatioclients, significantly reducing the cost and effort associated withapplications.

e
FactoryLink Architectur
11/11/2003

Link, the data services tier consists of a with FactoryLink), which provides advanced yLink also supports ODBC-compliant databases

ut can be developed and maintained from any n modifications are immediately available to all developing and maintaining FactoryLink

FactoryLink 7.2 Technical Overview of 30 11/11/2003

Scalability and Performance Due to its architecture, FactoryLink is inherently scalable. The client, business, and data services tiers can be distributed between computers in any manner, which provides incredible flexibility to the organization. Small applications can exist on a single computer, with all three tiers residing on the same computer. Larger applications can be distributed to separate computing resources. Typical Topologies Single-station architecture for small applications Multistation architecture for medium and large-sized applications Redundant architecture for high availability and fault tolerant applications Distributed architecture for communication between separate applications

FactoryLink Development/Run-time Systems are used to develop applications locally or remotely. They can also be used to run a FactoryLink application. Additional Client Access Licenses (CALs) may be purchased for distributed applications. Development CALs or Run-time CALs are available. Development systems come bundled with one Development CAL. Both Development CALs and Run-time CALS may be added to Development/Run-time systems. Development/Run-time systems contain configuration tools for developing both the server and the client applications. Configuration Explorer is the tool used to build the server application; Client Builder and Application Editor are the tools used to develop graphical user interfaces for the clients. The Application Editor (APPEDIT) is included for backward compatibility with FactoryLink 6.x systems or earlier with ECS Graphics and only supports development on the local system. FactoryLink Run-time Only Systems are used to run a completed application and cannot be used for development purposes. Run-time Only systems come bundled with one Run-time CAL. Additional CALs may be purchased for distributed applications, but only Run-time CALS may be added to Run-time systems.


FactoryLink Clients FactoryLink CALs are required for any user who configures or accesses run-time data (via OPC or any other means) from a server. Clients have the capability to access a server or servers over the network, or clients may be installed on the same computer as the server that holds their license. FactoryLink Development CALs can be used for concurrent development. Each FactoryLink Development CAL includes Configuration Explorer for building the server application and Client Builder for building the client application. The Application Editor is included for backward compatibility. FactoryLink Run-time CALS can be used to access server applications locally, but do not have configuration capability. Rich or Thin Clients FactoryLink systems and clients can be molded into the size needed. The thinnest clients access server-based clients using Windows Terminal Services. The richest clients are full systems installed across a LAN communicating with other systems. And there are many options in between.


Scalable System Sizes FactoryLink is designed to run FactoryLink applications of various sizes, with limits defined for the number of external inputs and outputs (I/O Tags) to the system and total number of tags defined in the system (Total Tags). Versions with smaller tag counts offer all of the same features as the unlimited version, as long as the same options are purchased. The sizes available for both Development/Run-time and Run-time Only Systems are shown in the following table.

FactoryLink Stand-Alone Systems include one server bundled with one local CAL, which must be installed on the same PC as the server and cannot connect to other systems. Additional CALs may not be added to these stand-alone systems. FactoryLink Stand-Alone System (75 I/O Tags - 1200 Total Tags) FactoryLink Stand-Alone System (150 I/O Tags - 2400 Total Tags) All the following FactoryLink SCADA Systems include one server bundled with one local CAL, which must be installed on the same PC as the server. Additional CALs may be added to these systems and the CALs can connect to other systems. FactoryLink System (300 I/O Tags - 4800 Total Tags) FactoryLink System (500 I/O Tags - 8000 Total Tags) FactoryLink System (1000 I/O Tags - 16000 Total Tags) FactoryLink System (1500 I/O Tags - 24000 Total Tags) FactoryLink System (3000 I/O Tags - 48000 Total Tags) FactoryLink System (5000 I/O Tags - 80000 Total Tags) FactoryLink System (8000 I/O Tags - 128000 Total Tags) FactoryLink System (15000 I/O Tags - 240000 Total Tags) FactoryLink System (35000 I/O Tags - 560000 Total Tags) FactoryLink System (50000 I/O Tags - 800000 Total Tags) FactoryLink System (Unlimited I/O and Total Tags)

Developer-Defined Tag Element Maximum (Total Tags) Except for the unlimited version, FactoryLink is designed to process a limited number of developer-defined real-time database elements (tags) per application. The total number of tags available to you is determined by your licensing agreement. This total is in addition to the predefined elements provided with a new, blank application. All elements of tag arrays are counted toward this total. Each time you configure an element during configuration, FactoryLink adds it to the total count of elements you have defined for that application. At run time, FactoryLink checks the application to determine the number of developer-defined elements. If the application has more than the licensed number of elements defined, the application will not run. A FactoryLink system can be converted to a larger size FactoryLink System by paying a conversion fee. Input/Output Element Maximum (I/O Tags) FactoryLink contains tasks for connecting to external devices. An I/O element is any element that is the source or target of any FactoryLink I/O task. An I/O task is any task that communicates directly with an external device, such as a computer, a PLC, or nodes on a network. These I/O tasks and their associated elements (tags) are a subset of the maximum number of elements you can configure for an application. FactoryLink is designed to process up to the maximum number of I/O tag elements in any of the I/O tasks provided or sold as options with FactoryLink.


Key Technical Features Client Builder, FactoryLink’s graphical

development tool, provides a rich set of artwork for use in building graphical displays. Also included are standard user interfaces for alarm viewing, trending, and historical data browsing. These interfaces require minimal configuration and allow you to present the right information to the right person in an easy-to-understand format.

FactoryLink has object-oriented development

tools. Application Objects represent real-world devices, such as pumps, valves, switches, tanks, or other equipment. Application Objects are reusable and have inheritance, so if one is modified, all instances of the object would be modified accordingly, without the need to find and update each one individually. These objects save valuable time and reduce risks during system configuration or maintenance efforts.

The FactoryLink system was designed to take full advantage of the Microsoft Windows operating system,

enabling users to leverage other software products available on the market and to lower training and maintenance costs. FactoryLink 7.2 runs on Microsoft Windows 2000 and Windows XP. Licenses for Microsoft SQL Server 2000 and Microsoft VBA are included in the product at no additional charge.

FactoryLink’s virtual real-time

networking capability facilitates the creation of redundant FactoryLink applications. It allows two identical FactoryLink applications to operate in a master/slave configuration and supports master/slave arbitration, real-time data synchronization, and alarm system redundancy. FactoryLink also supports several methods of handling redundancy of historical data.

The FactoryLink .NET Client supports access from the client to the server application across any

TCP/IP connection, such as public Internet, LAN, WAN, or other remote methods. Client Builder now uses Microsoft’s new .NET services to communicate through firewalls using Web Services, HTTP, and SOAP. (This is similar to the functionality that was previously provided by WebClient with ECS graphics and has been updated for this release.)

Rich Library of Graphical Images

Now Featuring Microsoft VBA


FactoryLink was built with global companies in mind. Tecnomatix supplies FactoryLink 7.2 in English, French, and German. Client Builder supports other languages as well, with system menus in English, French, German, and Spanish. Client screens can be built to display any language desired.

Localization of FactoryLink and

its applications for additional languages can also be provided due to the separation between the language-dependent dictionaries and the product code. The internal character representation uses multiple-byte storage, so a large variety of languages may be supported, such as Chinese or Korean.

Many applications require the ability to display the same application data on one client in one language and

on another client or clients in a second or third language. For example, an application for the Channel Tunnel might display data in French at the French side of the tunnel and in English at the other side.

Another requirement for multilingualism is related to the role that can be assigned to an operator. For

example, the text message (string value) displayed for a particular variable can be different according to the role of the current operator as he or she visualizes the underlying process. For example, a text message might be “Pump out of order” for an operator, and the same field might display “Pump out for scheduled maintenance” for a maintenance operator. Also, it is possible to mix the multilingual capabilities with the need for multiple roles. (Please note that some ActiveX Controls, such as Alarm Viewer have not been translated in FactoryLink and are planned enhancements for future releases.)

Many applications built before FactoryLink 7.0 used both a shared domain and a user domain. In

FactoryLink 7.0, the user domain was still available, but could only be used with ECS graphics, not with Client Builder. For 7.0 applications using Client Builder, most or all of the functionality provided by user tags could be implemented within Client Builder, through local variables and scripting, making user domain tags unnecessary. Migrating existing user-domain applications to Client Builder however, sometimes proved to be difficult. OPC access to user-domain tags is now supported for FactoryLink 7.2, making these available from Client Builder or any third-party OPC client.


Another important feature is Branching. In all previous versions, FactoryLink has presented a flat namespace view of its server tags to the user. Even if the tags actually represented attributes of a hierarchical system, they were all presented in list form. For systems with large numbers of tags, this made browsing for tags when creating Client Builder animations very time consuming. In FactoryLink 7.2, the OPC server presents a hierarchical view based on the tag names. The underscore “_” character is the primary branch separator. Many existing FactoryLink applications already use underscores as field separators in their tag naming convention and can immediately benefit from this feature. One of the most powerful applications of this feature is for applications that use Application Objects to generate their tags. The Application Objects can be configured to generate tag names that reflect the object hierarchy, which can then be easily seen from the browser.

In addition to streamlining the variable browsing, the branching functionality can also be used with Client

Builder's branching capability. For example, a symbol can be created using several tags representing a frequently repeating part of the hierarchy. This same symbol can then be opened using a specific branch and will display the attributes of that branch, without having to manually copy and modify separate instances. (For FactoryLink applications where this new behavior is not desired, the feature can be turned off from Client Builder.)

New Hierarchical View The left pane shows branches, while the right pane shows any “leaves” on the selected branch. Once the user clicks on a specific leaf, the full item string is displayed in the Selection box. In this example, you can see that wherever there were underscores in the tag-names, these are now displayed as branches in the tree.

Example of the flat namespace view in the variable-browser


FactoryLink has an Operator Logbook that provides the following functionality:

Operators enter notes about alarms or events. Information is saved in relational database for later reporting and analysis. When both ECS Graphics and Client Builder run on the same system, the Operator Logbook is the

collection of the operator inputs from the two different environments. The logbook is useful for applications that must comply with regulatory requirements.

An enhanced communications interface (ECI) supports scaling, data conversion, and a variety of

statistical calculations. FactoryLink also includes an enhanced OPC Client (ODX) that eliminates the need to purchase a

proprietary device interface in many systems. Not only does this reduce the cost of the software, it ensures the use of a standard protocol, making the system easier to maintain and upgrade.

A new Application Setup Wizard guides users through the set-up process and allows them to select from

three templates to create a FactoryLink application with basic configuration. The template applications are fully configurable baseline applications with functionality common to most FactoryLink applications. Using any of these template applications as a foundation, users can modify the existing components to meet their industry-specific needs, reducing the time and effort required to configure and maintain a new application. The new templates provide a jump start for application development by providing the following functionality:

Various screen navigation examples and techniques Application objects for easier setup for OPC, PLC communications, and redundant applications Multilanguage support Basic timers

FactoryLink includes a conversion utility to help users convert existing applications to the latest version.

Previous versions of FactoryLink and FactoryLink++ are upwardly compatible with FactoryLink 7.2. The upgrade is available at no charge for customers who have current Software Upgrade Service (SUS) or Customer Support Services (CSS) contracts. Upgrade pricing is available for customers without SUS or CSS.

FactoryLink 7.2 has a new feature to disable the Ctrl-Alt-Delete command so that operators are not able to

reboot the computer or access operating system functions.


FactoryLink Tasks At run time, FactoryLink tasks gather, process, communicate, and present data through the real-time database via a group of user-selectable options. Most tasks are included in the base FactoryLink 7.2 system at no additional charge. The most important tasks are described below.

Graphical User Interface Client Builder, FactoryLink’s graphical user interface, is an OPC client that communicates with the FactoryLink Server and other OPC servers. For supervisory control, instructions can be sent from Client Builder to the FactoryLink Server’s Real-Time Database and from there to the plant floor. The FactoryLink Server has an OPC Server task, which allows it to communicate with the FactoryLink Client and higher-level business systems, such as Manufacturing Execution Systems (MES) and Enterprise Resource Planning (ERP) in a standard way. Client Builder also supports alarming, trending, and historical data browsing functionality via ActiveX controls. An ActiveX control is provided for each of these functions and requires minimal configuration to achieve a fully functional system. Prior to FactoryLink 7.0, the graphical user interface for FactoryLink was called ECS graphics. Screens in this format are compatible with FactoryLink 7.2 and may be used inside of Client Builder graphics. Device Interfaces FactoryLink gathers data from devices such as programmable logic controllers (PLCs) and remote terminal units (RTUs). In addition to vendor-specific interfaces (for equipment from companies such as Schneider Electric, Omron, Rockwell, Siemens, and GE Fanuc), FactoryLink provides an OPC interface that can be used to collect information without requiring device-specific drivers. Real-time values are retrieved by the FactoryLink OPC Client or device-specific interface and are written into the real-time database. Values from the real-time database can also be sent to the plant floor devices to control the manufacturing process. Starting with FactoryLink 7.2, the OPC Client task now supports the VT_ARRAY data type. This saves configuration time since multiple PLC data points can now be mapped to a FactoryLink tag array using a single configuration entry.

Sample FactoryLink Mimics


OPC Data eXchange (ODX) ODX is an enhanced OPC Client that is used to communicate to PLCs and other OPC-compliant devices. It is included as a standard part of each FactoryLink 7.2 system. Its main features include:

Supports communication between a FactoryLink system and one or multiple OPC Servers Supports the entire ECI functionality including the redundancy setup Supports efficient block data exchange by accessing OPC Item Arrays in an OPC Server Supports OPC Items or Item Arrays to be decoded and conditioned as required

Enhanced Communication Interface (ECI) The Enhanced Communication Interface task is included as a standard part of each FactoryLink 7.2 system. It is essentially an I/O translator that provides an interface between various device interfaces and the FactoryLink real-time database. The ECI task supports various types of FactoryLink device interfaces, including OPC, RAPD, and EDI. Key features of ECI include: Decoder/EncoderSupports most data formats including bits, nibbles, and bytes from/to analogs, floats,

and digital arrays. Conversion of strings, BCD, Hex, and floating-point values is also supported. Scaling and OffsetSupports linear (y = mx + b) scaling for both inputs and outputs. Action-ReactionSupports the Action-Reaction principle resulting in increased system responsiveness and

increased usability for an operator. Statistical DataSupports statistical functions including maximum/minimum calculations, low pass filter

with adjustable attenuation, sum, squared sum, mean and standard deviation. Device Interface Purchasing Options An OPC interface is included in each FactoryLink system. Users may also select any two of the part numbers from the Standard Drivers list below at no additional charge. Additional interfaces may be purchased, if required. Standard Drivers Part Number Description 2000*GEF*FL*71 General Electric Fanuc 2000*GPI*FL*71 General Purpose Interface 2000*OMR*FL*71 Omron Hostlink 2000*RCK*FL*71

Rockwell Bundle: RAPD (supports: ControlNet, NetDTL, KTDTL, Asynch; prev. ABT). Also includes legacy Asynch (ABA), KTDTL (AKT), and NetDTL (ADT)). Requires RSLinx OEM 2.31, which is not included.

2000*SCH*FL*71 Schneider Bundle: Modbus Ethernet (prev. MBE); Modbus Plus (prev. MBP); Modbus Plus RAPD (prev. MBR), Modbus Serial (prev. MBS), Square D Serial/Ethernet Symax (Only Serial supported on XP, prev. (SQD).


2000*SIE*FL*71 Siemens Bundle: CP525 - EDI Serial (prev. SIE); EDI H1MP S5 (Windows 2000 only, DLC protocol, prev. SH5); 3964R - RAPD Serial for S5 and S7 PLCs (prev. SIR). S7D not included.

2000*TIW*FL*71 Texas Instruments TIWAY Other Drivers In addition to the Standard Drivers, the device interfaces in the following list are also available for purchase. Part Number Description 2000*FLG*FL*71 FL GEM Semiconductor Interface 2000*MEE*FL*71 Mitsubishi MECOM Serial and Ethernet Driver 2000*MES*FL*71 Mitsubishi MECOM Serial Driver 2000*OPT*FL*71 Opto 22 Optomux 2000*ETH*FL*71

Schneider Device Interface Bundle: TE Load, TE DRQ, ETHWAY for April Line, TE COM, UNI-TELWAY, MODNET 1 SFB for A Line PLCs, and KS Function for A Line PLCs)

2000*SGS*FL*71 SECS with GW Libraries RS232/Serial 2000*SGW*FL*71 SECS with GW Libraries HSMS/Ethernet 2000*S7D*FL*71

Siemens S7 Driver, Includes Enhanced Communications Interface [ECI] - supports Industrial Ethernet TCP/IP or ISO Stack, Profibus, and Multi-Point Interface Protocols

Timed Events and Intervals Event and interval timing is used to define timed events and time intervals that can be used to initiate and control any system function. Timed Events occur at a specific time not more than once every 24 hours, whereas Time Intervals occur at least once every 24 hours at regular intervals. Timed events and intervals can be used as triggers to other FactoryLink processes. Programmable Counters Programmable counters provide a count-per-unit-of-time measurement and event delays. Outputs from counters can be used to provide inputs to other FactoryLink processes or to trigger events. Real-time Database Browser and Debugger Tool The Database Terminal (DBT) is an on-line real-time browser that supports read/write access to a FactoryLink application to provide enhanced debugging capabilities. Advanced functionality is provided for viewing data including filters, wildcards, spreadsheet style display, change counters, and data format selection (ASCII, binary, hex, octal, decimal, exponential). Remote real-time database browsing can also be achieved from any enterprise network node through the Virtual Real-time Network and Redundancy task.


Math and Logic Operations The Interpreted Math and Logic task incorporates a programming language to perform operations of a mathematical or logical nature on combinations of data elements in the real-time database. Each Math and Logic operation is controlled by a procedure resembling BASIC, is based on user-defined variables, and is triggered by changing values in the real-time database. Compiled Math and Logic Operations (Optional Task) The Compiled Math and Logic task is used for applications that have a large number of calculations in the server application. It is used in conjunction with a C compiler and has the following advantages: Faster startup and execution, leading to improved performance Better handling of complex statements Ability to access third-party libraries Ability to call C functions or to insert C code into procedures

Alarms and Events System-wide event logging capability is supported in FactoryLink, with logging of three primary event types: Events from within the FactoryLink system, such as a network problem or a software task error Events from the PLC or other control system, such as a circuit breaker tripping, a pump stopping, or a cycle

finishing Operator interactions, such as when an operator logs in, starts a pump, or acknowledges an alarm

Alarms represent a subset of events and are configured based on any event within the system. Alarms are specifically intended to alert operators to situations that may require their action. Operators acknowledge alarms to indicate that they are aware of alarm existence. Alarms are acknowledged individually or by group. Alarms can also be disabled, so that they are no longer seen in the alarm list nor logged to the database. All actions such as disabling or enabling of alarms are logged as an operator action. Client Builder includes an Alarm Viewer that provides for viewing and acknowledging alarms or events in the system. It has filtering and sorting capabilities to make the information more useful to the operator. Alarms can be grouped in a hierarchical fashion to make it easier to diagnose problems and resolve them more quickly. Groups can be used for alarm filtering and can show the aggregate status of all the alarms in the group. Alarms from the viewer can also be seen like an alarm banner on a graphics screen, so an operator can monitor the latest alarms without displaying the full alarm screen. Events and states of various objects can also be viewed from the Alarm Viewer

Example of FactoryLink’s Alarm Viewer

11/11/2003

.


VRN provides a communication infrastructure suitable for a variety of distributed FactoryLink architectures, including both client/server and peer-to-peer. It also provides an interface directly to OLE for Process Control (OPC). Additionally, VRN facilitates the creation of redundant FactoryLink applications. It allows two identical FactoryLink server applications to operate in a master/slave configuration. In this capacity VRN supports master/slave arbitration, real-time data synchronization, and alarm system redundancy.

Report Generator FactoryLink can create reports based on data in the real-time database. Reports are flexible in format and can be generated as disk files, printed reports, or ASCII files exchanged with other applications. The Report Generator can also generate reports in XML format. These reports can be used to interchange information over the Internet with other applications that understand XML or can be formatted as HTML-viewable web pages. Reports can also be created using third-party software such as Microsoft Access and Crystal Reports to access historical data logged to an external database, such as SQL Server, Oracle, or Sybase. Virtual Real-time Network, Hot Standby, and Redundancy The Virtual Real-time Network and Redundancy (VRN) task provides networking and redundancy functionality for FactoryLink. VRN incorporates an Action-Reaction principle to improve system responsiveness so it increases usability for an operator. Data changes made on a client are seen immediately, and are updated on the server in the background. The Action-Reaction functionality also reduces network traffic by allowing transactions to be buffered and sent in periodic blocks. VRN supports redundancy using identical FactoryLink server applications. It does this by mirroring a selectable portion of the FactoryLink real-time database. VRN requires virtually no configuration work. Tag selection is done by a simple list that allows for the use of wildcards. A typical setup is shown below.

VRNTandem

VRNTandem

RedundantFactoryLinkDatabases

incl. Distributed

Alarm Logger

Router

GraphClient

GraphClient

GraphClient

GraphClient

DBXTerminal

VRNClient FactoryLink

Database

GraphClient

GraphClient

DatabaseRemoteAccess

Virtual Realtime Network TCP/IP

RemoteOperatorStations


It is important to know exactly what we mean by redundancy, since this term is interpreted in a variety of ways by various vendors. Depending on the specific audience, redundancy could be described as any of the following:

Second Server Function Availability, Use, and Investment Cost

Waiting to be installed from stock Considerable downtime at low cost Cold Standby Fully installed but not running Short downtime at moderate cost

Waiting for auto takeover at failure High or highest availability at high cost Hot

Standby Running and fully operative (FactoryLink with VRN)

High availability AND usage at moderate cost

Redundancy minimizes downtime and loss of data due to a system failure. While a cold-standby system may be adequate for some cases, it may require trained personnel to reinstate the standby system after a failure. This, together with a prolonged period of downtime, may cost more than a hot-standby server including the required software. Therefore, a hot-standby solution, as provided with FactoryLink, is normally the best value/cost option. How does redundancy using VRN compare to fault-tolerant products? Some of the highlights are: VRN is a high-availability clustering product that supports both real-time data and load balancing. VRN is an alternative to a fault-tolerant product for real-time data but not for historical data. Redundancy

of historical data can be configured using a relational database that supports clustering, such as SQL Server, Enterprise Edition. A system can also be configured for redundancy of historical data using two relational databases and replication techniques. FactoryLink supports both methods.

FactoryLink and VRN with a redundant historian database would be the preferred solution for applications that can afford historical data to be unavailable for a few seconds. Fault-tolerant solutions may be preferred for applications that must sustain high-value, high-throughput transactions without any pause.

Historian FactoryLink’s Historian task communicates with external databases to create, write to, read from, and update database tables. It processes data requests from other FactoryLink tasks and sends them to the external database. The Historian acts like an interface between FactoryLink and the database. The Historian is specific for a particular database product. The supported databases are: SQL Server 2000 using ODBC (Standard Edition included with FactoryLink) Oracle 9i Sybase ASE 12.5 Other relational databases with ODBC support, such as Informix and DB2/2 Dbase IV (for legacy applications)

These tasks can be thought of as “clients” of the Historian, because they make requests of the Historian. Depending on the task, they make requests to either put data in the database or retrieve data from the database. The Historian services the “client” tasks by processing their requests.


Because the client tasks do not communicate directly with the historical database, they do not have to be specifically configured for a particular database product. They remain generic. A benefit of this structure is that minimal work is required to change the application to connect to a different relational database should the need arise. When using Microsoft SQL Server (supplied with FactoryLink), the user relies on the Enterprise Manager to manage database actions such as backup, restore, import, or export, in addition to limiting database growth to a specific size. Unlike most SCADA or HMI products, all of FactoryLink’s historical data is stored in a relational database rather than a proprietary format. This makes access to the data easier and faster, without the need to write custom code to convert the data to a standard format.

Native Oracle Historian Interface The Oracle Historian task provides a native interface to an Oracle 9i relational database. It processes data requests from other FactoryLink tasks to write data to or retrieve data from the relational database. With this interface, users can store and retrieve their alarm, trend, recipe, and other historical data directly between FactoryLink and the Oracle Database. Also, Power SQL and the Database Browser tasks can write, read, and update records in the database. This capability is rarely seen in similar software packages and is a powerful feature of FactoryLink. For users with Oracle relational databases, this option provides the option of accessing up-to-the-minute historical data from FactoryLink without the need for exporting and conversion utilities. Native Sybase Historian The Sybase Historian task provides a native interface to a Sybase ASE 12.5 relational database. It processes data requests from other FactoryLink tasks to write data to or retrieve data from the relational database. With this interface, users can store and retrieve their alarm, trend, recipe, and other historical data directly between FactoryLink and the Sybase database. Also, Power SQL and the Database Browser tasks can write, read, and update records in the database. This capability is rarely seen in similar software packages and is a powerful feature of FactoryLink. For users with Sybase relational databases, this option provides the option of accessing up-to-the-minute historical data from FactoryLink without the need for exporting and conversion utilities. Data-Point and Database Logging Data-Point Logging was developed to simplify the task of logging data by providing preconfigured tables. Multiple shared numeric-value tags can be stored in the same database and sorted later if necessary. Data-Point Logging builds a database that will capture for the specified tag, the time, the tag name, and the tag value. Database Logging allows you to create a table and specify which tags to capture in that table. When the value of any tag in the table changes, the values of all tags in the table are logged. Database Logging provides the ability to group tags in a database table.

The FactoryLink tasks that use an external database via the Historian are: Distributed Alarm Logger Database Logger and Data Point Logger Trend Database Browser Power SPC Power SQL


Trending The Trend Control provided in Client Builder allows you to interact with the FactoryLink Trend Server. Users are capable of viewing the real-time or historical evolution of any data values previously configured for logging. Data values are displayed graphically using either a line graph or a bar graph. Trending handles multiple points (up to eight trends per viewer) and supports panning and zooming. A wide variety of pen styles and colors can easily be configured. On-line property changes let you “see it your way.” Database Browser The Database Browser Control provided in Client Builder connects to a relational database, such as SQL Server, and allows you to view data in a tabular fashion from the database. The view is updated periodically to show the most recent acquisition. Sorting and filtering are also supported. PowerSQL The FactoryLink PowerSQL (Structured Query Language) task works in conjunction with the FactoryLink Historian tasks to allow an application to access data in an external relational database through a result window. In addition, PowerSQL processes SQL statemFactoryLink message tag. Some of the features of PowerSQL are as follows: Works with a variety of FactoryLink Historians, such as SQL Server, Oracle, Allows data in an external relational database to be manipulated from within Allows an application to send and retrieve data to and from external database

outside FactoryLink Supports the execution of database-stored procedures for database servers wit

ExBro
Examples of FactoryLink’s FlexibleTrend Viewer
11/11/2003

ents that are entered in a

or Sybase FactoryLink tables, including those created

h this functionality

ample of FactoryLink wser Control


Operator Event Log A new Operator Event Log makes it easier to build applications that comply with regulatory requirements. The Operator Event Log logs all changes (events) made by an operator of a FactoryLink application. Whenever the operator performs some action that changes a tag’s value from the client project, the OPC Server creates events. Client Builder events, such as connections and disconnections, are also logged.

All of these events are automatically recorded in a database with the following fields: Time that the event occurred Name of the operator Type of event, such login, logout, connect, disconnect, update A message associated with the event is built automatically that contains: Operator ’XYZ’ Logged In Operator ’XYZ’ Logged Out TagXYZ changed to ’3.14’ Client ’NodeName’ Connected Client ’NodeName’ Disconnected

Name of the tag whose value changed Tag's new value after the change Tag's value immediately before the change The node name of the computer where the client is running

Power Statistical Process Control - PowerSPC (Optional Task) The PowerSPC task contains many standard statistical calculations and charts. It works in conjunction with the FactoryLink Historian tasks to allow an application to store and access real-time statistical data in an external relational database. The PowerSPC task is supported in ECS graphics format only. Programmer’s Access Kit (Optional, Part Number 2000*PAK*FL*72) The optional FactoryLink Programmer’s Access Kit (PAK) is a collection of FactoryLink software tools and related documentation that allows developers to design and construct FactoryLink-compatible tasks. Tasks developed with the PAK are completely integrated into the FactoryLink system and are configured the same as Tecnomatix-developed FactoryLink tasks.


The FactoryLink Programmer’s Access Kit (PAK) is used to: Create new tasks that perform functions not performed by standard FactoryLink tasks Develop communication interfaces to computers or devices for which standard interface tasks are not

already developed Unlike any other open architecture system, FactoryLink fully integrates a customer-written task into the FactoryLink environment. FactoryLink’s Configuration Explorer fully supports new tasks with full-screen editing, context-sensitive help, and documentation utilities. The PAK option also contains a Configuration PAK (CFGPAK) that allows users to access FactoryLink’s configuration data. The CFGPAK is a collection of software libraries, C-language source tasks, and related documentation used to design and construct tasks that directly manipulate the configuration databases of a FactoryLink application. Users generally configure tasks, or more specifically configuration databases, using FactoryLink’s Configuration Explorer. Configuration Explorer provides an interactive, graphical interface to view, add, modify, and/or delete task information within a particular application. As the user alters this task configuration, Configuration Explorer maintains the application integrity by validating new records, creating undefined tags, and recording the location of tag references. Tasks created with CFGPAK are able to automate many of the operations found in Configuration Explorer, saving users from manually importing and exporting configuration data. For example, a programmable logic controller (PLC) software package could scan the active PLC addresses and enter corresponding read/write records into that driver’s configuration databases. This option is particularly useful for companies that use FactoryLink as a platform to integrate with other products that they sell.


Configuration Tools FactoryLink provides both engineering and operational functionality. The engineering interface allows users to configure and maintain the system. The engineering tools supplied with FactoryLink include Client Builder for configuring the graphical user interface on the client tier and Configuration Explorer for the server component. Some of the key features of the configuration tools are covered in the following sections. For each function that is configured within Client Builder and Configuration Explorer, access is given to powerful Help tools. On-line Help content is structured much the same as an operator manual, with chapters, folders and subfolders. To find specific information, users can perform a full text search using the search engine facility. Client Builder Client Builder allows FactoryLink mimics (graphical screens) to be configured and viewed. Animation is possible during runtime via links between graphical elements and real-time tags on the FactoryLink server. In addition to mimics, Client Builder allows standard viewers such as Alarm, Trend, and Browser ActiveX Controls to be embedded in mimics. These ActiveX controls are also configured within the Client Builder environment. It is also possible to have new or third-party ActiveX controls embedded in Client Builder graphics. FactoryLink ECS graphics screens (in 6.6 or earlier) can be used inside Client Builfrom an older version of FactoryLink. Both graphics editors are provided with Facsystems. Customization is supported in Client Builder through Microsoft VBA scripting. Aavailable at runtime are accessible programmatically. Client Builder supports on-line configuration by providing the capability to devethe same environment. It is also possible to view displays in full screen mode at rupossible to lock access to undesired keystrokes to prevent undesired operator accessystem.

Example of FactoryLink Client Builder Configuration Environment

11/11/2003

der, so it is easy to upgrade toryLink development

ll animations and functions

lop and test graphics within n-time as required. It is s to the underlying operating


Client Builder’s main characteristics include: Client Builder elements can be edited, combined, and

stored in libraries for reuse, project after project. This applies to graphical symbols, configured mimics, control panels, templates, and scripts.

Client Builder includes a comprehensive library of graphical objects. This is a collection of images that may be used to create symbols to represent anything from a simple button to a complex piece of equipment including numerous animations. A symbol may be nested within other symbols.

Client Builder is a Multiple Document Interface (MDI) application, with floating toolbars and toolboxes. Tools and windows offer such tools as ToolTips and on-line Help facilities. In addition, each window can also be assigned a security level to restrict nonauthorized user access.

Client Builder is an ActiveX container and therefore, any compatible third-party ActiveX control is capable of being inserted into a Client Builder mimic. ActiveX controls are included for viewing alarms, events, and state changes within FactoryLink.

Client Builder uses the standard Microsoft Visual Studio-style

environment for VBA script editing and debugging. Every graphical item such as drawings, animations, symbols, mimics, and user profile, are completely changeable by altering their properties in VBA scripts.

Drawings or graphical objects may be rotated, mirrored, aligned,

grouped, ungrouped, locked, unlocked, dragged, and dropped.

Symbols are class based and object oriented. Each time a symbol is modified, all replications (or instances) are automatically updated graphically as well as in database links. Symbols and libraries may be predefined or user defined.

Mimics are easily tested and modified by using the multiple window facility. A particular mimic is shown simultaneously in its design and run-time mode within two separate windows. Modifications made in the design window are immediately applied to the run-time graphic.


Configuration Explorer FactoryLink 7.2 has a server configuration environment, Configuration Explorer, which is intended to make the system intuitive for novice users and to increase productivity for power users. (It is a replacement for the old Configuration Manager used in FactoryLink 6.6 or earlier versions.) Configuration Explorer was built using standard Microsoft Windows user interface techniques and presents an environment that is highly intuitive to those with experience using Microsoft products. It supports a multi-user, client/server configuration environment where multiple users can configure multiple servers concurrently from any machine on the network. Configuration Explorer has a number of core components including: Menu bars and tool bars Enterprise View Tag Browser Editors

The Enterprise View appears by default on the left-hand side of the configuration environment annavigational window, providing a hierarchical system tree view. It shows the various servers withsuch as FactoryLink servers and OPC servers, and allows you to navigate to these servers and coFor FactoryLink servers, the tree shows the associated applications, tasks, and task configurationhierarchical fashion. Context menus are available for all items in the tree to show the options avaspecific item. Selecting an item in the tree will launch the appropriate editor for that item. For FactoryLink tasks, this is either the Configuration Editor or the Math and Logic Editor. The Configuration Editor is used to edit FactoryLink configuration tables. As well as providing the traditional grid view of the task (records listed down the page in a tabular fashion) it also provides for a form view. A form view allows for the configuration of a single record via a user-friendly form interface. If a Math and Logic procedure is selected from the Enterprise View, then the Math and Logic Editor is launched. This provides an intuitive and user-friendly method for creating Math and Logic procedures and includes features such as chromacoding (text color based on syntax) and automatic update of the trigger and variable tables directly from the editor.

ChroMa

P

FactoryLink Configuration

Explorer

11/11/2003

d is the key in the system,

nfigure them. s in a ilable for that

macoding in a th and Logic rocedure


Other key features of Configuration Explorer include: Importing configuration data from external sources such as text files or spreadsheets Generation of configuration data based on a repeatable pattern Deep copying (such as copying child records associated with a particular parent) of configuration data

between different applications Copying of configuration data between different tables; for example, copying tags from a driver

configuration table to the alarms configuration table Objects and Classes Configuration Explorer provides the capability to define “models” or “classes” called Application Objects. They are used to represent real-world items or devices found in the process. Application Objects are reusable and have inheritance. Each replication of a class is called an instantiated object. If a class were modified, all instances derived from that class would be modified accordingly. Additionally, a class can be configured to obtain its parameters from a variety of places including an Excel spreadsheet, text file, any ODBC data source, or manual input. Application Objects permit preconfigured system configuration for specific types of applications. Software developers can concentrate on software objects; domain experts configure application-oriented classes (domain layer); while an application team uses the application objects to quickly construct and tailor the system for a specific application. An Application Object is constructed by aggregating built-in objects and other existing Application Objects into a new class. The subobjects and their connections define the functionality of the Application Object. The use of Application Objects in development can greatly reduce the total cost of ownership of the system, especially for large projects. Branching Branching improves productivity by allowing a user to create a Client Builder symbol that references a branch and specific tags within that branch. Subsequent instances of these symbols are then configured by changing only the name of the branch. All the symbols on a mimic can be grouped into a complex symbol that also supports this functionality. A branch is a group of tags or other branches. The term “branch” is used because a hierarchical data structure is often referred to as a “tree” in computer science. Trees contain branches and leaves. A simple example of a hierarchical data structure that might exist in an industry is shown at the right.

Configuration


The branches in this example are Area1, Pump1, Pump2, and Pump3. Branches exist simply to group tags (leaves) together into subsets. The actual tags in this system are the Upstream Pressures, Downstream Pressures, and Speeds. To represent this hierarchy in a flat database, the following naming convention is used. Each of these names defines a single tag. Area1_Pump1_UpstreamPressure Area1_Pump1_DownstreamPressure Area1_Pump1_Speed Area1_Pump2_UpstreamPressure Area1_Pump2_DownstreamPressure Area1_Pump2_Speed Area1_Pump3_UpstreamPressure Area1_Pump3_DownstreamPressure Area1_Pump3_Speed The number of hierarchy levels that can be defined is limited only by the maximum length of the FactoryLink tag name. To configure the first symbol, the user creates the graphical representation of the object and then animates the graphical representation by referencing tags contained in a single branch. The symbol may not reference tags from multiple branches.

Pump1

UpstreamPressure

Speed

DownstreanPressure

For subsequent instances of this symbol, the user is only required to specify the name of the branch to identify which set of tags are used for the animation. The symbol automatically provides the references to the tags within this branch.

Pump2

UpstreamPressure

Speed

DownstreanPressure


For symbols with limited animation, this is not much of a savings. However, for symbols with large amounts of animation, this is a huge productivity gain. All the work is put into the first symbol. You then cut and paste this symbol multiple times only changing the name of the branch to identify a different set of tags for it to reference. This is an example of a graphic that can be quickly built using this functionality. In addition, it is possible to change the name of the branch at run-time. This can be done programmatically via script. For example, the following symbol and buttons could be combined into one symbol that could be used to show the data for various pumps on one mimic. The difference is that the operator must press the Previous/Next buttons to view the data from the other sets (branches) of pump tags. In addition, the name of the branch could be specified on a mimic open action so the following mimic could be opened from different buttons and the data displayed would be from the branch specified in the mimic open action.

Combining the above functionality with Application Objects provides a powerful configuration environment. Application Objects provides the ability to define a set of tags as a class (a class and a branch can be synonymous) and instantiate this set of tags many times. To maintain the system, the user changes the class definition and all instances are updated automatically. The same is done for symbols. Any change made to the symbol automatically takes effect the next time the user opens the mimic. Other Benefits Of Branching Using branching with a good tag naming convention will improve the performance of the Variable Brower when developing a system with a large number of tags. The reason for this is because branching is a natural filter. When branching is used, the user does not access all tags in the FactoryLink database and display them in the Variable Browser. Instead, only the tags that belong to the branch are accessed and displayed. The user will significantly improve system performance (and lower development time) by defining a good tag naming convention and using branching. FactoryLink 6.x did not have hierarchical tags or branching capabilities. A popular applications technique used in many of the installed systems was to use array tags to reduce complexity in larger applications. Starting with FactoryLink 7.2, to support array tags, FactoryLink will auto-generate a second OPC name for each array tag.


Planning Your Application A well-planned application can make the task of building and maintaining the application much cheaper and simpler. Some of the basic things that you should consider when planning your application are listed here. Tag naming concept Messaging concept Screen organization Redundancy requirements Application objects needed OPC or other proprietary drivers Security and levels of users

Tag Naming Concept One of the most important parts of planning an application is to define a tag naming convention before you start developing. Perhaps your plant already has a well-defined standard, but if not, some general recommendations for tag names are outlined in the user documentation, which can be used to save you time. Some of the key points are listed in the box at the right. Following these tag-naming recommendations has the following advantages: Configuration requires minimum work since an object or group of

objects including all properties can be specified by a single entry. Objects can be automatically generated. This applies especially to

Application Objects that create object properties and their configuration table entries. You can then instantiate as many Application Objects as you wish for one or more objects using a single entry.

Text for a large number of tags can be automatically generated. Sort order shows composite elements. Groups or individual

objects and their properties can be found easily using standard branching and browsing methods. This makes testing and troubleshooting much easier.

Types of Messages As part of developing your standard application, you should consider the types of messages that will be presented to users. For example, you may want to distinguish between two types of alarm messagesthose that need immediate attention (such as failure and warning alarms) and those that can be taken care of later (such as diagnostics and status information messages).

Tag-Naming Recommendations Have a hierarchical structure Incorporate the type of process,

unit, and location in the name (but not addresses or references that may change during the lifetime of an item)

Distinguish between process-related and system-related objects, for example, a motor including all of its I/O signals may be part of the process whereas the I/O card that takes the signals may be part of a PLC system

Define virtual objects including all of its I/O signals and interface borders

Use a consistent naming system throughout the plant

Have a way to distinguish acquired tags from internal system tags

Preferably, plant-related hardware inputs/outputs (for example, push buttons, lamps, feedback signals) should use the same tag-naming concept to indicate the devices (machine, unit, switch, or any source within the plant) to which it belongs


Application Objects and Symbols An important part of building an application that is easy to expand and maintain is to define standard Application Objects and symbols to represent various classes of objects to be controlled. For example, you might use the analogy of specifying an operator interface for a standard automobile. You would define the instrument panel with all the buttons, switches, and gear required to run the car. Similarly with FactoryLink, you might specify the user interface for a pump. You would define the control panel with the buttons required to operate the pump in Client Builder. Then, each time you need a new pump, you would use the associated pump object to create another instance of the pump. Using Application Objects improves the quality of a FactoryLink application by encouraging structured development, reducing errors, and improving maintainability. Standard Operator Interface One standard that should be considered when designing an application is the concept of having a standard interface for operators. By taking the time to define a standard interface you can improve system performance, minimize operator errors, and lower training and maintenance costs. The Starter Application provided with FactoryLink serves as a demonstration and practice application to help users learn about FactoryLink’s capabilities and features. This application contains a suggested framework for an application, and is fully configurable for those who want to practice customizing the application. It contains a number of predefined application objects for standard OPC inputs and outputs. When you use the Application Setup Wizard to create your FactoryLink application, you choose from three templates with basic configuration, which provides a dramatic effect on the total cost of building and maintaining the application. You can think of it as a jump start for application development. The wizard templates are preconfigured with the following functionality: Screen navigation Redundancy OPC Data eXchange Application objects Basic timers Multilanguage support

You have a choice with FactoryLinkyou can start with a completely blank application or you can start developing on top of a wizard template. By using the a template as the basis for your plant’s standard application, not only do you shorten development time, but you make an application that is easy to maintain and build upon for future plant expansions. The template also has the advantage of having a standardized operator interface, so it is easier to move operators between systems and reduces training requirements.


Customer Support Services An important part of planning a system is to plan for future maintenance and enhancement of the system. Support and upgrade programs are available to help ensure your success with Tecnomatix products by providing easy access to phone support, on-line support, software patches, and other software updates. The methods and levels of support are well defined so that there are no surprises should you experience a problem. Even minor releases contain valuable new features that give you improved functionality and added value. And, you know in advance what your costs will be and can plan your budgets accordingly. There are two distinct offerings that may be ordered separately or together as needed. One offering provides software upgrades and the other provides support via telephone or the Internet. The two options are summarized here: Software Upgrade Service (SUS) Part Number 2000*SUS*000 SUS includes: Major releases (upgrades) of system components currently licensed by user Minor releases (upgrades), updates, patches, and service packs Web-based access to the Tecnomatix on-line Knowledge Base utility for one person

Other details: SUS is available for purchase within 120 days from the purchase date of a new license or 120 days from the

purchase of an upgrade or within 60 days of the expiry of an existing SUS contract. SUS that has lapsed beyond the 60-day grace period may not be renewed. Service consists of a 12-month minimum term and 3-year maximum term. Import, shipping, and handling fees are not included.

Support Subscription Service (SSS) Part Number 2000*SSS*000 SSS includes: Patches and service packs Phone support from assigned support provider (usually the TOP in your area) Web-based access to the Tecnomatix on-line Knowledge Base utility for one person

Other Details: If SSS expires, you may renew at any time by buying a new SSS policy. It is not necessary to pay for the

months missed. Service consists of a 12-month minimum term and 3-year maximum term. Import, shipping, and handling fees are not included.

Both SUS and SSS are calculated based on the total price of all options owned, including systems, clients, options, and device interfaces. Three (3) months of warranty SSS and SUS are provided at no charge with the purchase of each new FactoryLink system. Talk to your FactoryLink sales consultant for more details on SUS, SSS, and Knowledge Base.


Hardware Guidelines Minimum and recommended hardware requirements for FactoryLink 7.2 are published in the Installation Guide and in the “FactoryLink 7.2 Hardware and Software Requirements” document. While the software will run on the minimum requirements in most cases, they may not be adequate for satisfactory performance on some systems, especially larger, complex systems. Since it is impossible to define the exact requirements for each system due to the flexibility and scalability of FactoryLink and other layered software involved, we have prepared additional guidelines to help you select the best estimate of system requirements. Your exact requirements may differ slightly from these guidelines. Please discuss your specific application with your FactoryLink sales consultant to determine the best hardware for your application. Small to medium applications will typically run with the following hardware configuration: Pentium 500 CPU, with 128 MB RAM CD-ROM drive for installation XVGA Monitor and graphics processor (1024 X 768, with at least 65K colors) Keyboard and Windows 2000/Windows XP-compatible mouse Hard drive space: 1.0 GB or larger for a FactoryLink Client, 2GB for a FactoryLink Server. More space

will be required if you plan to install SQL Server or to keep a large amount of historical data. Summary FactoryLink provides the process knowledge and control needed to perfect the products companies make and the processes they manage. FactoryLink is: Powerful Open Scalable Flexible Based on standards

With over 80,000 seats of FactoryLink installed in more than 60 countries worldwide, FactoryLink is a great foundation to usefrom the simplest HMI system to the most sophisticated SCADA system. Please contact your Tecnomatix sales representative for additional information.

Tecnomatix Technologies, Inc. 2435 North Central Expressway Richardson, TX 75080-2722 USA

http://www.tecnomatix.com/ (972) 680-9700 (877) 873-2821

COPYRIGHT 2003, Tecnomatix Technologies.

http://www.tecnomatix.com/

FactoryLink 7 2 Technical Overview Rev2

Documents

Transcript of FactoryLink 7 2 Technical Overview Rev2