Professional Documents
Culture Documents
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.
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.
FactoryLink provides visibility into the entire process, giving the right Based on Open Standards
information to the right people when they need it.
A graphical user interface lets operators monitor and control pumps, tanks, Microsoft Windows XP
valves, motors, switches, and other key process equipment. Microsoft Windows 2000
An alarm system alerts operators to problems and keeps a history for later Windows Terminal Services
analysis. support for remote access by
Real-time and historical trend charts help operators and managers improve thin clients
efficiency and resolve problems. OPC
Reports and historical data help satisfy management and regulatory ActiveX
requirements. ODBC
FactoryLink supports both local and remote monitoring to provide secure C++
access to critical information at the plant or even at a manager’s home. Microsoft Visual Basic for
FactoryLink connects RTUs, programmable controllers, production and test Applications (included)
equipment, business systems, and other supporting systems via OPC, XML, Microsoft SQL Server 2000
proprietary, or custom protocols, providing unparalleled connectivity. (included)
A rich set of artwork, developed specifically for industrial automation Microsoft .NET
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.
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 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.
FactoryLink applications are stored on the FactoryLink server, but can be developed and maintained from any
client in the system with a development license. Any application modifications are immediately available to all
clients, significantly reducing the cost and effort associated with developing and maintaining FactoryLink
applications.
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
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 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.
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)
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.
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.
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.
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.)
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.
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.)
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:
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.
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.
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
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.
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
Other Drivers
In addition to the Standard Drivers, the device interfaces in the following list are also available for purchase.
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.
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.
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.
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
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.
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.
The Virtual Real-time Network and Redundancy (VRN) task VRN provides a communication
provides networking and redundancy functionality for infrastructure suitable for a variety of
FactoryLink. VRN incorporates an Action-Reaction principle to distributed FactoryLink architectures,
improve system responsiveness so it increases usability for an including both client/server and peer-to-
operator. Data changes made on a client are seen immediately, peer. It also provides an interface directly
to OLE for Process Control (OPC).
and are updated on the server in the background. The Action-
Reaction functionality also reduces network traffic by allowing Additionally, VRN facilitates the creation of
transactions to be buffered and sent in periodic blocks. redundant FactoryLink applications. It
allows two identical FactoryLink server
VRN supports redundancy using identical FactoryLink server applications to operate in a master/slave
applications. It does this by mirroring a selectable portion of the configuration. In this capacity VRN
FactoryLink real-time database. VRN requires virtually no supports master/slave arbitration, real-time
data synchronization, and alarm system
configuration work. Tag selection is done by a simple list that
redundancy.
allows for the use of wildcards. A typical setup is shown below.
Database
Remote
Access
Redundant
VRN FactoryLink VRN VRN
DBX
Tandem Databases Tandem Terminal
Client FactoryLink
incl. Database
Distributed
Alarm Logger
Router
Virtual Realtime Network TCP/IP
Second
Function Availability, Use, and Investment Cost
Server
Cold Waiting to be installed from stock Considerable downtime at low cost
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
Running and fully operative High availability AND usage at moderate cost
Standby
(FactoryLink with VRN)
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.
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.
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 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.
Database Browser
PowerSQL
Works with a variety of FactoryLink Historians, such as SQL Server, Oracle, or Sybase
Allows data in an external relational database to be manipulated from within FactoryLink
Allows an application to send and retrieve data to and from external database tables, including those created
outside FactoryLink
Supports the execution of database-stored procedures for database servers with this functionality
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:
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.
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.
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.
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
FactoryLink ECS graphics screens (in 6.6 or earlier) can be used inside Client Builder, so it is easy to upgrade
from an older version of FactoryLink. Both graphics editors are provided with FactoryLink development
systems.
Customization is supported in Client Builder through Microsoft VBA scripting. All animations and functions
available at runtime are accessible programmatically.
Client Builder supports on-line configuration by providing the capability to develop and test graphics within
the same environment. It is also possible to view displays in full screen mode at run-time as required. It is
possible to lock access to undesired keystrokes to prevent undesired operator access to the underlying operating
system.
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.
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 FactoryLink
techniques and presents an environment that is Configuration
highly intuitive to those with experience using Explorer
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.
The Enterprise View appears by default on the left-hand side of the configuration environment and is the key
navigational window, providing a hierarchical system tree view. It shows the various servers within the system,
such as FactoryLink servers and OPC servers, and allows you to navigate to these servers and configure them.
For FactoryLink servers, the tree shows the associated applications, tasks, and task configurations in a
hierarchical fashion. Context menus are available for all items in the tree to show the options available for that
specific item.
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 Configuration
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.
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
Upstream
Pressure
Downstrean
Pressure
Speed
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
Upstream
Pressure
Downstrean
Pressure
Speed
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.
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.
Tag-Naming Recommendations
One of the most important parts of planning an application is to define
a tag naming convention before you start developing. Perhaps your Have a hierarchical structure
plant already has a well-defined standard, but if not, some general Incorporate the type of process,
recommendations for tag names are outlined in the user unit, and location in the name (but
documentation, which can be used to save you time. Some of the key not addresses or references that
points are listed in the box at the right. may change during the lifetime of an
item)
Distinguish between process-related
Following these tag-naming recommendations has the following
and system-related objects, for
advantages: example, a motor including all of its
I/O signals may be part of the
Configuration requires minimum work since an object or group of process whereas the I/O card that
objects including all properties can be specified by a single entry. takes the signals may be part of a
Objects can be automatically generated. This applies especially to PLC system
Application Objects that create object properties and their Define virtual objects including all of
its I/O signals and interface borders
configuration table entries. You can then instantiate as many
Use a consistent naming system
Application Objects as you wish for one or more objects using a throughout the plant
single entry. Have a way to distinguish acquired
Text for a large number of tags can be automatically generated. tags from internal system tags
Sort order shows composite elements. Groups or individual Preferably, plant-related hardware
objects and their properties can be found easily using standard inputs/outputs (for example, push
branching and browsing methods. This makes testing and buttons, lamps, feedback signals)
should use the same tag-naming
troubleshooting much easier.
concept to indicate the devices
(machine, unit, switch, or any source
Types of Messages within the plant) to which it belongs
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).
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.
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.
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.
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.
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.
Small to medium applications will typically run with the following hardware configuration:
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
from the simplest HMI system to the most sophisticated SCADA system.
foundation to use