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