Wonderware

Get Started. It's Free
or sign up with your email address
Rocket clouds
Wonderware by Mind Map: Wonderware

1. Extensions

1.1. Extendable attributes list

1.2. InputOutput Extension Group

1.3. Input Extension Group

1.4. Output Extension Group

1.5. Alarm Extension Group

1.6. History Extension Group

1.7. Boolean Extension Label

2. QuickScript .NET

2.1. Areas

2.1.1. 1 - Scripts

2.1.1.1. Shows all scripts currently associated with an object

2.1.2. 2 - Inherited scripts name

2.1.2.1. Shows all scripts associated with the objects parent

2.1.2.1.1. Shows if OnScan, Execute or OffScan and Shutdown

2.1.3. 3 - Configure execution order

2.1.3.1. Sets the execution order of multiple scripts both inherited and local

2.1.4. 4 - Aliases

2.1.4.1. Lets you create and modifyaliases that apply to the script you are workingon

2.1.4.2. Logically descriptive names for long ArchestrA reference strings to make more readable

2.1.5. 5 - Declarations

2.1.5.1. Provides a place to add a variable declaration

2.1.5.2. Declared variables are live from startup and can hold values that persist from one execution of the script to the next

2.1.6. 6 - Basics

2.1.6.1. Provides a location in which you set the expression, triggering conditions, and other settings that run the script in the run-time environment

2.1.7. 7 - Script State

2.1.8. 8 - Script Editor

2.1.8.1. Box - shows the script that's being written

3. The Plant Model

3.1. Plant

3.1.1. Section

3.1.1.1. Area

3.1.1.1.1. Production Line

4. Background Info

4.1. Terminology

4.1.1. HMI

4.1.1.1. Human Machine Interface

4.1.2. DCS

4.1.2.1. Distributed Control Systems

4.1.3. SCADA

4.1.3.1. Supervisory Control and Data Acquisition systems

4.1.4. PIM

4.1.4.1. Process Information Management

4.1.5. MES

4.1.5.1. Manufacturing Execution Systems

4.1.6. EMI

4.1.6.1. Enterprise Manufacturing Intelligence

4.1.7. IDE

4.1.7.1. Integrated Development Environment

4.1.8. ERP

4.1.8.1. Enterprise Resource Management

4.1.9. KPI

4.1.9.1. Key Performance Indicators

4.1.10. GUI

4.1.10.1. Graphical User Interface

4.1.11. ERM

4.1.11.1. Enterprise Resource Management

4.1.12. OOP

4.1.12.1. Object Oriented Programming

4.1.13. P&ID

4.1.13.1. Process and Instrumentation Diagram

4.1.14. UDA

4.1.14.1. User Defined Attributes

4.1.15. NaN

4.1.15.1. Not a Number

4.1.16. DQP

4.1.16.1. Data Quality Propagation

4.1.17. VTQ

4.1.17.1. Value, Time, Quality

4.1.18. SMC

4.1.18.1. System Management Console

4.1.19. VLMX

4.1.19.1. Visual Local Message Exchange

4.1.20. CMC

4.1.20.1. Console Menu Commands

4.1.21. RTU

4.1.21.1. Remote Terminal Unit

4.1.22. DDE

4.1.22.1. Dynamic Data Exchange

4.1.23. PLC

4.1.23.1. Programmable Logic Controller

4.2. System Platform

4.2.1. Industrial Domain Services

4.2.1.1. P2P communications

4.2.1.2. Central Alarming

4.2.1.3. Mobile Phone/ email alerts etc...

4.2.2. Software and device connectivity services

4.2.2.1. Integration of manufacturing and business systems

4.2.2.2. Migration

4.2.2.3. Communication of devices, systems, and HMIs

4.2.2.4. Historians and relational databases

4.2.2.5. Quality and maintenance systems

4.2.2.6. ERP and MES

4.2.3. Information and data management services

4.2.3.1. Realtime management

4.2.3.2. Data transfer and storage

4.2.3.3. Access to KPI

4.2.3.4. Offline handling for manual data

4.2.3.5. Data compression etc

4.2.4. Information-delivery and visualization services

4.2.4.1. Right info to right user and right time

4.2.4.2. Thick clients, thin clients, TSE

4.2.4.3. Full GUI

4.2.4.4. Trending Tools

4.2.4.5. Batch analysis

4.2.4.6. Open SQL access

4.2.4.7. Secure across firewalls

4.2.5. Application development services

4.2.5.1. Symbols

4.2.5.2. Development Views

4.2.5.3. Unification with MS Office Products

4.2.5.4. Development

4.2.6. System management and extensibility services

4.2.6.1. Easy expandabilltity

4.2.6.2. Redistribution of server load

4.2.6.3. central diagnostics

4.3. Business Aspects

4.3.1. Manufacturing

4.3.1.1. Collaborative data-driven environment

4.3.1.2. Synchronize process with schedule and plan(s)

4.3.1.3. Empower operators with critical information

4.3.1.4. Greatest possible return on assets

4.3.2. Challenges

4.3.2.1. Heavy initial investment

4.3.2.2. Outdated equipment and process

4.3.2.3. Lack of communication

4.3.2.4. Lack of centralized data

4.3.2.5. Old technology acts as anchor

4.3.2.6. Poor training

4.3.2.7. Difficult to execute change before market conditions change again

4.4. Galaxy Repository

4.4.1. the software sub-system consisting of one more galaxy databases.

4.5. Technology

4.5.1. DDE and SuiteLink I/O Addressing

4.5.1.1. 3 part naming convention

4.5.1.1.1. Node

4.5.1.1.2. Application

4.5.1.1.3. Topic

4.5.1.1.4. Item

4.5.2. OPC

4.5.2.1. Industrial automation standards

4.5.2.2. Open

4.5.2.3. Based off Windows DCOM (distributed component object model)

4.5.3. Device Integration Objects (DIObjects)

4.5.3.1. Automation Object that represents communication with external devices

4.5.3.2. Run on App engine

4.5.3.3. Representation of a physical connection to a didevice object via the data access server

4.5.4. DDESuiteLinkClient

4.5.4.1. DeviceIntergration object that allows access to a running I/O server

4.5.4.2. Provides data points to Galaxy application objects through the DDESuiteLinkClient object

4.5.4.3. Compatible with all Wonderware I/O SErvers and compontents

4.5.4.4. Reference Syntax

4.5.4.4.1. <objectname>.<topicname>.<itemname>

4.5.4.4.2. <objectname>.<topicname>.<attributename>

4.5.5. OPCClient

4.5.5.1. Used to connect to OPC DA (Data Access server)

5. Planning

5.1. Application Planning

5.1.1. Project Workflow

5.1.1.1. 1 - Identify Field Devices and Functional Requirements

5.1.1.1.1. Identify all valves, agitators, rakes, pumps, PID controllers etc.

5.1.1.1.2. Start with P&ID

5.1.1.1.3. Group multiple base objects for more complex objects known as "containments"

5.1.1.1.4. Inputs / Outputs

5.1.1.1.5. Scripts needed?

5.1.1.1.6. Historization / logs?

5.1.1.1.7. Alarms?

5.1.1.1.8. Security?

5.1.1.2. 2 - Define naming conventions

5.1.1.2.1. Object.Attributes

5.1.1.3. 3 - Define the area model

5.1.1.3.1. Logical grouping within application that defines area model

5.1.1.3.2. Examples

5.1.1.3.3. Alarms grouped by area

5.1.1.3.4. Can be nested

5.1.1.4. 4 - Plan templates

5.1.1.4.1. Make Valve / Motor / Other Templaes

5.1.1.5. 5 - Define the security model

5.1.1.5.1. Who has access to what?

5.1.1.6. 6 - Define the deployment model

5.1.1.6.1. Which object instances reside on what computer?

5.2. 10 Steps for OOP Development

5.2.1. 1. Site Survery

5.2.1.1. Understand Process

5.2.1.2. P&ID

5.2.2. 2. Equipment List

5.2.2.1. Group similar pieces (Motors, valves, etc)

5.2.2.2. Identify distinct areas of operation

5.2.3. 3. Templates are configured

5.2.3.1. Each common Device

5.2.3.2. Setup Standards

5.2.3.3. Develop objects

5.2.3.4. Contain Logic, I/O, scripting, history config, security and alarms & events

5.2.4. 4. Advanced Templates

5.2.4.1. Combine other templates to make a larger object

5.2.4.2. F.E. Add level transmittor, pump, inlet/outlet valve and agitator for a single "Mixer"

5.2.5. 5. Template Attributes

5.2.5.1. Device templates have attributes which represent real I/O available in the PLC or control system.

5.2.5.2. Often Linked to the I/O through Device Integration Objects

5.2.6. 6. Application Assembly

5.2.6.1. Drag & Drop in ArchestrA IDE

5.2.6.2. Links to all template parents

5.2.6.3. Create child objects

5.2.7. 7. Object Security

5.2.7.1. Assign objects to security groups

5.2.7.2. Groups have common permissions

5.2.7.3. Roles are assigned to groups

5.2.7.4. Users can be given more than one role

5.2.8. 8. Models deployed to computers

5.2.8.1. Sent to hosts

5.2.8.2. Fully distributed system - what computer things are installed on doesn't matter as it can always and easily change

5.2.9. 9. Graphics for HMI w/ InTouch

5.2.9.1. Allows graphics to be linked to templates in ArchestrA IDE

5.2.9.2. Graphics are object oriented and tied to Plant

5.2.10. 10. Maintenance

5.2.10.1. Changes to templates to propagate to child objects

6. Package Info

6.1. ArchestrA

6.1.1. The comprehensive industrial automation and information architecture that orchestrates a new way to run or expand older plants more efficiently and an optimal way to build new plants

6.2. Galaxy

6.2.1. "...The entire application, the complete ArchestrA system consisting of a single logical namespace and a collection of WinPlatforms, AppEngines and objects

6.2.2. Galaxy Database

6.2.2.1. the relational database containing all persistent configuration information for all objects in a galaxy

6.3. Automation Information Pyramid

6.3.1. 1. Plant Floor Connectivity

6.3.2. 2. Supervisory

6.3.3. 3. Production

6.3.4. 4. Plant Intelligence

6.3.5. 5. Manufacturing Collaboration

7. Application Objects

7.1. Templates and Instances

7.1.1. Allow for reuse of existing engineering

7.1.2. Template is an entity that represents the common functional requirements of a field device.

7.1.3. Requirements reflect info such as number of inputs and outputs, alarm conditions, history needs, security etc.

7.1.4. Created from either base or derived template

7.1.4.1. Base templates can not be modified

7.1.5. Like a "cookie cutter"

7.1.6. Propagate down from highest instance

7.2. $UserDefined Object

7.2.1. Provides basic functionality you need to develop an ArchestrA supervisory applicaiton

7.2.2. Field attributes, scripts, etc.

7.2.3. As Template or Container

7.2.3.1. Template

7.2.3.1.1. Have multiple attributes specific to this type of object

7.2.3.2. Container

7.2.3.2.1. Used as a container for other objects

7.2.3.2.2. Group various objects together to make complex objects

7.3. Attribute Locking

7.3.1. Unlocked - Both templates and instances can be unlocked. Object has its own copy of the attribute value

7.3.2. Locked - Only templates can be locked. Derived objects don't have a uniqu copy of the attribute value

7.3.3. Locked in Parent - Both can be locked.

7.4. $AnalogDevice

7.4.1. Configured as basic analog device

7.4.1.1. Alarming

7.4.1.2. History

7.4.1.2.1. Can be historized

7.4.1.3. Basic I/O

7.4.1.3.1. Process Value (PV)

7.4.1.3.2. Change PV = Change Field

7.4.1.3.3. Manual Mode = no PV

7.4.1.3.4. Scaled between raw counts and engineering unit values using either Linear or Square-Root conversions

7.4.2. OR analog regulator device

7.4.2.1. External model of PID controller

7.4.2.2. Still maintain traditional alarm & history

7.4.2.3. Basic I/O

7.4.2.3.1. Reading and optionally writing two separate analog signals from the field or from another object

7.4.2.3.2. PV read from field (except in manual); NEVER written

7.4.2.3.3. SP is written and read from field

7.4.2.3.4. Scaled between raw counts and engineering unit values using either Linear or Square-Root conversions

7.4.2.4. Controller mode

7.4.2.4.1. govern types of writes are allowed to the SP value withing system

7.4.2.4.2. Manual

7.4.2.4.3. Cascade

7.4.2.4.4. None

7.4.2.5. Control tracking

7.4.2.5.1. Boolean

7.4.2.5.2. Track flag

7.4.2.5.3. Read from external device

7.4.2.5.4. external controller "owns" the value of SP; the SP is purely read-only and cannot be commanded to be changed and output to the field

7.4.3. Alarm Conditions

7.4.3.1. Exceeds level limt (Lo, Hi, LoLo and HiHi)

7.4.3.2. Exceeds rate of change limits for both (+) and (-)

7.4.3.3. Exceeds major and minor deviations from a target value

7.4.3.4. Has a quality value of BAD

7.5. $DiscreteDevice

7.5.1. BACKGROUND INFO

7.5.1.1. All kinds of innate statistics built in

7.5.1.2. Input output states are totally independant of each other and can be configured

7.5.1.2.1. Can be linked by alarms

7.5.1.3. State names are mapped to boolean combos in truth table

7.5.1.3.1. Off / On

7.5.1.3.2. Open / Close

7.5.1.4. 2 or more physical states

7.5.1.4.1. open

7.5.1.4.2. closed

7.5.1.4.3. moving

7.5.1.5. Represents a large collection of physical equipment common in manufacturing

7.5.1.5.1. pumps

7.5.1.5.2. valves

7.5.1.5.3. motors

7.5.1.5.4. conveyors

7.5.1.6. General purpose application object

7.5.2. STATES

7.5.2.1. Passive

7.5.2.1.1. When idle, stopped, or closed (the typical non running position

7.5.2.2. First Active

7.5.2.2.1. Represents state of the discrete device when it is considered to be running. Ex - Motor is "forward"

7.5.2.3. Second Active

7.5.2.3.1. (optional)

7.5.2.3.2. Some discrete devices have more than one active state

7.5.2.3.3. EX - Motor is "backwards"

7.5.2.4. Transition

7.5.2.4.1. (optional)

7.5.2.4.2. In transition anytime it is changing state from one valid state to another

7.5.2.4.3. EX - Valve is moving from closed to open, Off to On and is "moving" or in transition

7.5.2.5. EXAMPLE

7.5.2.5.1. Transition

7.5.2.5.2. Closed

7.5.2.5.3. Open

7.5.2.5.4. Bad

7.5.2.5.5. Where 1=TRUE and 0=FALSE

7.5.3. Alarms

7.5.3.1. Command Timeout

7.5.3.1.1. Did not change states within the specified timeout period

7.5.3.2. Un-commanded change

7.5.3.2.1. State changed when it was not commanded to do so

7.5.3.3. Individual alarms for Active1, Active2, Fault, etc.

7.5.3.4. Duration alarms for Active1, Active2, Fault, etc.

7.5.4. Statistical features

7.5.4.1. Most recent time durations for Active1, Active2, Passive, etc

7.5.4.2. Total accumulated time duration of the states Active1, Active2, Passive, etc

7.5.4.3. Total number of transitions into the Active1, Active2, Passive, etc

7.5.4.4. A command able reset of the statistics

7.6. Containment

7.6.1. Relationship in which one builds another.

7.6.2. Organize objects in a hierarchy

7.6.3. Three kinds of names

7.6.3.1. 1 - Tagnames

7.6.3.1.1. Unique name of individual object - EX - Valve1

7.6.3.2. 2 - Contained name

7.6.3.2.1. Name of the object within the context of the container object. Example, Tagname Valve1 might be Tank1.Outlet, if Tank1 contains it and it is named "Outlet"

7.6.3.3. 3 - Hierarchical name

7.6.3.3.1. Fully qualified names of contained object and objects that contain it

7.6.3.3.2. If "Reactor1" contains "Tank1" (also known as "SurgeTank")

7.6.3.3.3. "Tank1" contains "Valve1" (also known as "outlet")

7.6.3.3.4. Then it is

7.6.4. *Only works with derived templates

7.7. UDAs

7.7.1. Background

7.7.1.1. Set alarms and historization attributes

7.7.1.2. Set initial vales and locks on new attribute

7.7.1.3. Specify attributes

7.7.1.4. Expose Behavior

7.7.1.5. Add Logic

7.7.1.6. User Defined Attributes

7.7.2. Can add to template or an instance

7.7.3. When added to instance, locked automatically in child instances

7.7.4. When added to a template, lock state derives lock state in child object

7.7.5. After attribute is added to an instance, it appears in the attribute browser list for use with the scripting and attribute extension functions

7.7.6. MAIN AREAS

7.7.6.1. UDAs List

7.7.6.1.1. list: Lists all UDAs currently associated with the object. Click add to add a new UDA

7.7.6.2. Inherited UDAs

7.7.6.2.1. list: Lists all UDAs associated with the objects parent. The object automatically includes these UDAs. They can only be edited by modifying the parent template

7.7.6.3. Data Type

7.7.6.3.1. list: Shows the data type options for configuring the selected UDA

7.7.6.4. Data types -

7.7.6.4.1. Boolean

7.7.6.4.2. Integer

7.7.6.4.3. Float

7.7.6.4.4. Double

7.7.6.4.5. String

7.7.6.4.6. Time

7.7.6.4.7. ElapsedTime

7.7.6.4.8. InternationalizedString

7.7.6.5. Categories

7.7.6.5.1. Calculated

7.7.6.5.2. Calculated retentive

7.7.6.5.3. Ojbect writable

7.7.6.5.4. User writable

7.7.6.6. Value

7.7.6.6.1. Specifies initial value

7.7.6.6.2. In the case of BOOLEAN, check box = true

8. $DDESuiteLinkClient

8.1. Can't automatically reconnect if connection is lost

8.2. Need to have script to add re-connection functionality

9. Alarms and Events

9.1. Background

9.1.1. An alarm and event provide a way for users to automate the detection, notification, historization and viewing of either application (process) alarms and events or system/software alarms/events

9.2. Alarms

9.2.1. Examples

9.2.1.1. Process measurement has exceededa predefined limit

9.2.1.1.1. example - High temperature alarm

9.2.1.2. Device is not in a desired state

9.2.1.2.1. Ex -pump that should be running has stopped

9.2.1.3. System hardware is not operating within desired limits

9.2.1.3.1. Ex - CPU utilization on a platform exceeds a certain percentage for and extended amount of time

9.2.2. Handling

9.2.2.1. The ArchestrA platform can be the Handler

9.2.2.1.1. Areas "subscribe" to platform handling as a Boolean checkbox

9.2.2.1.2. Routes all alarms and events to all areas that are subscrbed

9.2.2.2. ONLY ONE HANDLER EXISTS PER PLATFORM (Node)

9.2.2.3. Alarms carry User acknowledgement information for security

9.2.2.4. Alarms are mapped between ArchestrA field and InTouch Dist Alarms Mapping

9.2.2.4.1. Examples - Type, timestamp, Tag, Area, State, Priority etc.

9.2.3. Consumer

9.2.3.1. InTouch

9.2.3.1.1. Configured to subscribe to the alarm providers

9.2.3.1.2. Used to acknowledge and unacknowledge alarms

9.2.4. Queries

9.2.4.1. Used within alarm clients to retrieve real-time alarm information and event reports from the galaxy

9.2.4.2. The fully-qualified syntax on an alarm query to retrieve a single alarm within an object as reported by a specific WinPlatform object is:

9.2.4.2.1. \\nodename\Galaxy!area!object.attribute

9.2.4.3. If on local computer link is:

9.2.4.3.1. \Galaxy!area!object.attribute

9.2.5. Attributes

9.2.5.1. .Acked

9.2.5.1.1. Used to specify whether an alarm has been acknowledged.

9.2.5.1.2. Always set False when new alarm condition is detected

9.2.5.2. .AckMsg

9.2.5.2.1. Operator comment at the time of acknowledgement

9.2.5.3. .AlarmMode

9.2.5.3.1. Current Alarm setting - Enable, Disable or Silence

9.2.5.4. .AlarmModeCmd

9.2.5.4.1. Command to set the alarm mode - Enable, Disable or Silence

9.2.5.5. .Category

9.2.5.5.1. Category of the alarm. The label of each alarm category is fixed

9.2.5.6. .DescAttrName

9.2.5.6.1. Description of the alarm.

9.2.5.6.2. Must be a string or internationalizedstring

9.2.5.6.3. max length = 329 char

9.2.5.6.4. Can be static or me.AttrName

9.2.5.7. .InAlarm

9.2.5.7.1. Alarm state. Off when disabled.

9.2.5.8. .Inhibit

9.2.5.8.1. Used to disable individual alarm

9.2.5.9. .Priority

9.2.5.9.1. Value of urgency, 1-999 where 1 is most urgent

9.2.5.10. .TimeAlarmAcked

9.2.5.10.1. Timestamp indicated the last time this alarm was acknowledged. Date format reflects the current locale setting for the operating system.

9.2.5.11. .TimeAlarmOff

9.2.5.11.1. Timestamp indicating the last time this alarm (as represented by .InAlarm) went off. Based on current Locale

9.2.5.12. .TimeAlarmOn

9.2.5.12.1. Timestamp indicating the last time this alarm (as represented by .InAlarm) went on. Based on current Locale

9.3. Events

9.3.1. Examples

9.3.1.1. Plant process has started

9.3.1.1.1. Ex - new batch or campaign has started

9.3.1.2. Operator has changed a plant operator parameter

9.3.1.2.1. Ex - Setpoint on temperature controller

9.3.1.3. System engineer has changed the runtime system configuration

9.3.1.3.1. Ex - Deployment of new AutomationObject

9.3.1.4. Platform comes back online (after shutdown or failure)

9.3.1.5. User Logins

9.3.1.6. Detection of a severe software problem

9.3.1.6.1. Ex - failed application object component

9.4. NOT Alarms and Events (examples

9.4.1. Configuration actions within the Galaxy Repository

9.4.1.1. Ex - Object check-in or check-out

9.4.2. Installation of bootstrap on a PC

9.4.3. Message sent to sys logger (SMCLogger)

9.4.4. Viewing a window in the View Engine

9.5. Alarm Modes

9.5.1. Enabled

9.5.1.1. All alarms for an object are reported to client applications and saved as historical data.

9.5.1.2. Less restrictive than the silenced or disabled alarm states

9.5.2. Silenced

9.5.2.1. All alarms for an object are detected, saved to history, and sent to alarm clients.

9.5.2.2. Do not show alarms.

9.5.2.3. More restricted than the enabled state, but less restricted than disabled

9.5.3. Disabled

9.5.3.1. No alarms for the object are detected.

9.5.3.2. The alarm is return-to-normal until the alarm is re-enabled.

9.5.3.3. The disabled state is more restrictive than the silenced and enabled alarm states

9.5.3.4. Does not require acknowledgement

10. Historization

10.1. Background

10.1.1. One or more products can be installed on the same network as the application server galaxy

10.1.2. Box running historian does not have same requirements as ArchestrA since data is "pushed"

10.1.3. One-to-One mapping between historized object and a tag in Wonderware Historian

10.2. Configuration

10.2.1. Attributes

10.2.1.1. Numerical

10.2.1.2. Non-Numerical

10.2.2. Reconfiguration of object at redeploy time

10.3. Extension

10.3.1. Force Storage Period

10.3.1.1. Time in ms in which attribute is saved to historian

10.3.2. Value Deadband

10.3.2.1. ABS(Engineering Units) in order for new data point to be logged

10.3.2.2. Used to eliminate momentary small fluctuations

10.3.3. Interpolation Type

10.3.3.1. List of methods used by the historian to interpolate analog historical data

10.3.3.2. Types

10.3.3.2.1. Linear

10.3.3.2.2. Stairstep

10.3.3.2.3. Default

10.3.4. Rollover Value

10.3.4.1. Positive INT that represents a tag's reset limit when historian is operating in counter retrieval mode.

10.3.4.2. Uses rollover to calculate Delta (change)

10.3.5. Trend Hi

10.3.5.1. Initial maximum trend value in EU for clients.

10.3.5.2. Default is 100

10.3.6. Trend Lo

10.3.6.1. Initial minimum trend value in EU for clients.

10.3.6.2. Default is 0

10.3.7. Sample Count

10.3.7.1. Number of samples the historian should store in the active image for an attribute value

10.3.7.2. 0 - 9999

10.3.7.3. Historian forces value of 65

10.3.8. Enable Swinging Door

10.3.8.1. Flag that indicates whether the swinging door rate deadband is enabled or disabled.

10.3.8.2. Default is disabled

10.3.8.3. Disabled automatically for BOOL or String

10.3.9. Rate Deadband

10.3.9.1. % rate of change deadband based on the change in the slope of incoming data values to the historian.

11. Security

11.1. Background

11.1.1. Designed to prevent users from performing unauthorized activities

11.1.1.1. Including Users of:

11.1.1.1.1. ArchestrA IDE when configuring and deploying objects

11.1.1.1.2. The SMC (System Management Console)when performing maintenance and system administration functions

11.1.1.1.3. View (or other GUI client applications) when performing runtime operations including monitoring, control and data entry functions

11.1.1.1.4. Other future ArchestrA utilities

11.1.2. Designed to support normal operating procedures of applications

11.1.3. Not designed to stop malicious access to the system.

11.1.4. Can be configured to support OS authentication mapped to OS account(s)

11.2. Configuration Steps Overview

11.2.1. 1 - Enabling security

11.2.2. 2 - Defining security model

11.2.3. 3 - Mapping users to the security model

11.2.4. 4 - Mapping AutomationObjects to the security model

11.2.5. *** If the security is not enabled then authentication mode is disabled

11.3. Authentication Method(s)

11.3.1. None

11.3.1.1. Default for new galaxies

11.3.1.2. Considered "open security"

11.3.1.3. No authentication is provided

11.3.2. Galaxy

11.3.2.1. Uses local galaxy configuration

11.3.2.2. System controlled by galaxy configuration

11.3.3. OS User Based

11.3.3.1. Uses NT based user authentication

11.3.4. OS Group Based

11.3.4.1. Uses NT based group authentication with advanced options

11.3.4.1.1. Login TIme

11.3.4.1.2. Role Update

12. Galaxy Maintenance

12.1. Exporting and Importing

12.1.1. Background

12.1.1.1. Share objects with other users in other Galaxies

12.1.2. Exporting

12.1.2.1. Only checked in versions are exported

12.1.2.2. Exports as .aaPKG

12.1.2.3. When exporting an object instance it includes parents of the object all the way up to the base

12.1.2.4. ***Scripts are NOT transferred with export and must be done separately

12.1.2.5. Can do Export all

12.1.3. Importing

12.1.3.1. Reuse from galaxy to galaxy

12.1.3.2. Import from .aaPKG

12.1.3.3. Import from .aaPDF

12.1.3.3.1. .aaPDF contains the configuration data and implementation code for one or more base templates

12.1.3.3.2. .aaPDF is created by ArchestrA Object Toolkit

12.1.3.4. *Can NOT have two objects with the same name or more than one copy of the same version of an object in the same Galaxy

12.2. Configuring Instances through a .CSV File

12.2.1. Galaxy Dump

12.2.1.1. Objects instances and their configuration data can be exported to a comma-delimited format Galaxy dump file (.csv)

12.2.1.2. Only dumps instances

12.2.1.3. Templates can NOT be dumped

12.2.1.4. Contains versions only for checked-in objects

12.2.1.5. Attributes that are locked are NOT `Saved

12.2.1.5.1. *Seems like an issue which would render this ineffective

12.3. System Management Console (SMC)

12.3.1. Background

12.3.1.1. SMC provides ArchestrA application server all kinds of diagnostics by allowing you to view the run-time status of some system objects and to perform actions upon those objects

12.3.1.2. Used to assist system integrators and system administrators in performing administrative tasks & diagnostics

12.3.1.3. Can run in a "safe mode"

12.3.1.4. Provides the ability to set Platforms and Engines OnScan or OffScan

12.3.1.5. Uses local platform as the gateway to the ArchestrA application

12.3.1.6. Does not rely on Galaxy repository to exist

12.3.1.7. Allows viewing of the layout of Galaxy repository, platforms and engines

12.3.1.8. Provides the ability to start and stop Platforms and Engines

12.3.1.9. Tools

12.3.1.9.1. VLMX Tool

12.3.1.9.2. DAServer Manager

12.3.1.9.3. LogViewer

12.3.1.9.4. Bookmarks

12.3.1.9.5. Platform Manager

12.3.1.9.6. Network Account Utility

13. Device Integration Products

13.1. Wonderware I/O Servers

13.1.1. Background

13.1.1.1. Microsoft Windows application programs that enable DDE (dynamic data exchange) with other DDE aware windows apps (InTouch, Excel) access to data in the "real world" such as PLCs or RTUs

13.1.1.2. All I/O setup is done specific to the environment

13.1.2. Configuring I/O servers

13.1.2.1. Once the I/O server has been installed, some configuration is required

13.1.2.2. File named MODBUSDV.CFG stores configuration information

13.1.2.3. Configured with Modicon MODBUS - Com Port Settings

13.1.2.4. Configure definitions for PLC

13.2. Wonderware Data Access Servers

13.2.1. Background

13.2.1.1. DA (Data Access) server is designed to provide simultaneous connectivity between client apps based on Wonderware Suitelink, OPC and DDE protocols being translated.

13.2.1.2. Uses DA Server manager

13.2.1.3. Features "Hot" configuration - ability to change dynamically while system is up and running live

13.2.2. Architecture

13.2.2.1. Three physical parts

13.2.2.1.1. 1 - Plug-in Component(s)

13.2.2.1.2. 2 - DAS Engine

13.2.2.1.3. 3 - Device Protocol Layer

13.3. Device Integration Objects

13.3.1. Background

13.3.1.1. Device Integration (DI) represent the applications networks and devices, and mirror the actual device hierarchy

13.3.1.1.1. DI Network Object

13.3.1.1.2. DI Device Object

13.3.1.2. Represent communication channels and field controllers

13.3.2. Advantages

13.3.2.1. Allow for config, deployment and monitoring of DAServers from one centralized location

13.3.2.2. Can represent all devices and PLCs in a network, enabling full plant representation and connectivity

13.3.2.3. Closely tied to the DAServer to that when object is deployed across the network it remotely installs the DAServer - meaning install can happen without going to actual machine, and that the DAServer connects immediately.

14. Multi-Node Applications

14.1. Application Redundancy

14.1.1. Background

14.1.1.1. Redundancy is important in processes that rely on continuous availability of information

14.1.1.2. Ensure continuous operation by providing an engine that remains active in the event of a single system compoinentfailyre

14.1.1.3. One is "active" one is "standby"

14.1.1.4. Engine --> Redundancy

14.2. DI Redundancy

14.2.1. For all intensive purposes function as "standalone objects" IE - don't have redundant "states"

14.2.2. Set to enable continuity of I/O information

14.3. Multi Node Application

14.3.1. Standalone to Network Configuration

14.3.2. Each node contains

14.3.2.1. Bootstrap

14.3.2.2. ArchestrA IDE

14.3.2.3. Galaxy Repository

14.3.3. Multi User Configuration

14.3.3.1. Setup for other nodes

14.3.3.1.1. 1 - Create Galaxy to which all other nodes will connect

14.3.3.1.2. 2 - Create platforms for other galaxy members

14.3.3.1.3. 3 - Rename the node

14.3.3.1.4. 4 - Name and deploy their own Platform as the first Platform deployed on the Galaxy

15. New topic

15.1. sadasdsa

15.1.1. aasdaS

15.1.1.1. ASDASDSA

15.1.1.2. asdasd

15.2. b

15.3. c

15.4. d