1. QuickScript .NET
1.1. Areas
1.1.1. 1 - Scripts
1.1.1.1. Shows all scripts currently associated with an object
1.1.2. 2 - Inherited scripts name
1.1.2.1. Shows all scripts associated with the objects parent
1.1.2.1.1. Shows if OnScan, Execute or OffScan and Shutdown
1.1.3. 3 - Configure execution order
1.1.3.1. Sets the execution order of multiple scripts both inherited and local
1.1.4. 4 - Aliases
1.1.4.1. Lets you create and modifyaliases that apply to the script you are workingon
1.1.4.2. Logically descriptive names for long ArchestrA reference strings to make more readable
1.1.5. 5 - Declarations
1.1.5.1. Provides a place to add a variable declaration
1.1.5.2. Declared variables are live from startup and can hold values that persist from one execution of the script to the next
1.1.6. 6 - Basics
1.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
1.1.7. 7 - Script State
1.1.8. 8 - Script Editor
1.1.8.1. Box - shows the script that's being written
2. Background Info
2.1. Terminology
2.1.1. HMI
2.1.1.1. Human Machine Interface
2.1.2. DCS
2.1.2.1. Distributed Control Systems
2.1.3. SCADA
2.1.3.1. Supervisory Control and Data Acquisition systems
2.1.4. PIM
2.1.4.1. Process Information Management
2.1.5. MES
2.1.5.1. Manufacturing Execution Systems
2.1.6. EMI
2.1.6.1. Enterprise Manufacturing Intelligence
2.1.7. IDE
2.1.7.1. Integrated Development Environment
2.1.8. ERP
2.1.8.1. Enterprise Resource Management
2.1.9. KPI
2.1.9.1. Key Performance Indicators
2.1.10. GUI
2.1.10.1. Graphical User Interface
2.1.11. ERM
2.1.11.1. Enterprise Resource Management
2.1.12. OOP
2.1.12.1. Object Oriented Programming
2.1.13. P&ID
2.1.13.1. Process and Instrumentation Diagram
2.1.14. UDA
2.1.14.1. User Defined Attributes
2.1.15. NaN
2.1.15.1. Not a Number
2.1.16. DQP
2.1.16.1. Data Quality Propagation
2.1.17. VTQ
2.1.17.1. Value, Time, Quality
2.1.18. SMC
2.1.18.1. System Management Console
2.1.19. VLMX
2.1.19.1. Visual Local Message Exchange
2.1.20. CMC
2.1.20.1. Console Menu Commands
2.1.21. RTU
2.1.21.1. Remote Terminal Unit
2.1.22. DDE
2.1.22.1. Dynamic Data Exchange
2.1.23. PLC
2.1.23.1. Programmable Logic Controller
2.2. System Platform
2.2.1. Industrial Domain Services
2.2.1.1. P2P communications
2.2.1.2. Central Alarming
2.2.1.3. Mobile Phone/ email alerts etc...
2.2.2. Software and device connectivity services
2.2.2.1. Integration of manufacturing and business systems
2.2.2.2. Migration
2.2.2.3. Communication of devices, systems, and HMIs
2.2.2.4. Historians and relational databases
2.2.2.5. Quality and maintenance systems
2.2.2.6. ERP and MES
2.2.3. Information and data management services
2.2.3.1. Realtime management
2.2.3.2. Data transfer and storage
2.2.3.3. Access to KPI
2.2.3.4. Offline handling for manual data
2.2.3.5. Data compression etc
2.2.4. Information-delivery and visualization services
2.2.4.1. Right info to right user and right time
2.2.4.2. Thick clients, thin clients, TSE
2.2.4.3. Full GUI
2.2.4.4. Trending Tools
2.2.4.5. Batch analysis
2.2.4.6. Open SQL access
2.2.4.7. Secure across firewalls
2.2.5. Application development services
2.2.5.1. Symbols
2.2.5.2. Development Views
2.2.5.3. Unification with MS Office Products
2.2.5.4. Development
2.2.6. System management and extensibility services
2.2.6.1. Easy expandabilltity
2.2.6.2. Redistribution of server load
2.2.6.3. central diagnostics
2.3. Business Aspects
2.3.1. Manufacturing
2.3.1.1. Collaborative data-driven environment
2.3.1.2. Synchronize process with schedule and plan(s)
2.3.1.3. Empower operators with critical information
2.3.1.4. Greatest possible return on assets
2.3.2. Challenges
2.3.2.1. Heavy initial investment
2.3.2.2. Outdated equipment and process
2.3.2.3. Lack of communication
2.3.2.4. Lack of centralized data
2.3.2.5. Old technology acts as anchor
2.3.2.6. Poor training
2.3.2.7. Difficult to execute change before market conditions change again
2.4. Galaxy Repository
2.4.1. the software sub-system consisting of one more galaxy databases.
2.5. Technology
2.5.1. DDE and SuiteLink I/O Addressing
2.5.1.1. 3 part naming convention
2.5.1.1.1. Node
2.5.1.1.2. Application
2.5.1.1.3. Topic
2.5.1.1.4. Item
2.5.2. OPC
2.5.2.1. Industrial automation standards
2.5.2.2. Open
2.5.2.3. Based off Windows DCOM (distributed component object model)
2.5.3. Device Integration Objects (DIObjects)
2.5.3.1. Automation Object that represents communication with external devices
2.5.3.2. Run on App engine
2.5.3.3. Representation of a physical connection to a didevice object via the data access server
2.5.4. DDESuiteLinkClient
2.5.4.1. DeviceIntergration object that allows access to a running I/O server
2.5.4.2. Provides data points to Galaxy application objects through the DDESuiteLinkClient object
2.5.4.3. Compatible with all Wonderware I/O SErvers and compontents
2.5.4.4. Reference Syntax
2.5.4.4.1. <objectname>.<topicname>.<itemname>
2.5.4.4.2. <objectname>.<topicname>.<attributename>
2.5.5. OPCClient
2.5.5.1. Used to connect to OPC DA (Data Access server)
3. $DDESuiteLinkClient
3.1. Can't automatically reconnect if connection is lost
3.2. Need to have script to add re-connection functionality
4. Alarms and Events
4.1. Background
4.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
4.2. Alarms
4.2.1. Examples
4.2.1.1. Process measurement has exceededa predefined limit
4.2.1.1.1. example - High temperature alarm
4.2.1.2. Device is not in a desired state
4.2.1.2.1. Ex -pump that should be running has stopped
4.2.1.3. System hardware is not operating within desired limits
4.2.1.3.1. Ex - CPU utilization on a platform exceeds a certain percentage for and extended amount of time
4.2.2. Handling
4.2.2.1. The ArchestrA platform can be the Handler
4.2.2.1.1. Areas "subscribe" to platform handling as a Boolean checkbox
4.2.2.1.2. Routes all alarms and events to all areas that are subscrbed
4.2.2.2. ONLY ONE HANDLER EXISTS PER PLATFORM (Node)
4.2.2.3. Alarms carry User acknowledgement information for security
4.2.2.4. Alarms are mapped between ArchestrA field and InTouch Dist Alarms Mapping
4.2.2.4.1. Examples - Type, timestamp, Tag, Area, State, Priority etc.
4.2.3. Consumer
4.2.3.1. InTouch
4.2.3.1.1. Configured to subscribe to the alarm providers
4.2.3.1.2. Used to acknowledge and unacknowledge alarms
4.2.4. Queries
4.2.4.1. Used within alarm clients to retrieve real-time alarm information and event reports from the galaxy
4.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:
4.2.4.2.1. \\nodename\Galaxy!area!object.attribute
4.2.4.3. If on local computer link is:
4.2.4.3.1. \Galaxy!area!object.attribute
4.2.5. Attributes
4.2.5.1. .Acked
4.2.5.1.1. Used to specify whether an alarm has been acknowledged.
4.2.5.1.2. Always set False when new alarm condition is detected
4.2.5.2. .AckMsg
4.2.5.2.1. Operator comment at the time of acknowledgement
4.2.5.3. .AlarmMode
4.2.5.3.1. Current Alarm setting - Enable, Disable or Silence
4.2.5.4. .AlarmModeCmd
4.2.5.4.1. Command to set the alarm mode - Enable, Disable or Silence
4.2.5.5. .Category
4.2.5.5.1. Category of the alarm. The label of each alarm category is fixed
4.2.5.6. .DescAttrName
4.2.5.6.1. Description of the alarm.
4.2.5.6.2. Must be a string or internationalizedstring
4.2.5.6.3. max length = 329 char
4.2.5.6.4. Can be static or me.AttrName
4.2.5.7. .InAlarm
4.2.5.7.1. Alarm state. Off when disabled.
4.2.5.8. .Inhibit
4.2.5.8.1. Used to disable individual alarm
4.2.5.9. .Priority
4.2.5.9.1. Value of urgency, 1-999 where 1 is most urgent
4.2.5.10. .TimeAlarmAcked
4.2.5.10.1. Timestamp indicated the last time this alarm was acknowledged. Date format reflects the current locale setting for the operating system.
4.2.5.11. .TimeAlarmOff
4.2.5.11.1. Timestamp indicating the last time this alarm (as represented by .InAlarm) went off. Based on current Locale
4.2.5.12. .TimeAlarmOn
4.2.5.12.1. Timestamp indicating the last time this alarm (as represented by .InAlarm) went on. Based on current Locale
4.3. Events
4.3.1. Examples
4.3.1.1. Plant process has started
4.3.1.1.1. Ex - new batch or campaign has started
4.3.1.2. Operator has changed a plant operator parameter
4.3.1.2.1. Ex - Setpoint on temperature controller
4.3.1.3. System engineer has changed the runtime system configuration
4.3.1.3.1. Ex - Deployment of new AutomationObject
4.3.1.4. Platform comes back online (after shutdown or failure)
4.3.1.5. User Logins
4.3.1.6. Detection of a severe software problem
4.3.1.6.1. Ex - failed application object component
4.4. NOT Alarms and Events (examples
4.4.1. Configuration actions within the Galaxy Repository
4.4.1.1. Ex - Object check-in or check-out
4.4.2. Installation of bootstrap on a PC
4.4.3. Message sent to sys logger (SMCLogger)
4.4.4. Viewing a window in the View Engine
4.5. Alarm Modes
4.5.1. Enabled
4.5.1.1. All alarms for an object are reported to client applications and saved as historical data.
4.5.1.2. Less restrictive than the silenced or disabled alarm states
4.5.2. Silenced
4.5.2.1. All alarms for an object are detected, saved to history, and sent to alarm clients.
4.5.2.2. Do not show alarms.
4.5.2.3. More restricted than the enabled state, but less restricted than disabled
4.5.3. Disabled
4.5.3.1. No alarms for the object are detected.
4.5.3.2. The alarm is return-to-normal until the alarm is re-enabled.
4.5.3.3. The disabled state is more restrictive than the silenced and enabled alarm states
4.5.3.4. Does not require acknowledgement
5. Historization
5.1. Background
5.1.1. One or more products can be installed on the same network as the application server galaxy
5.1.2. Box running historian does not have same requirements as ArchestrA since data is "pushed"
5.1.3. One-to-One mapping between historized object and a tag in Wonderware Historian
5.2. Configuration
5.2.1. Attributes
5.2.1.1. Numerical
5.2.1.2. Non-Numerical
5.2.2. Reconfiguration of object at redeploy time
5.3. Extension
5.3.1. Force Storage Period
5.3.1.1. Time in ms in which attribute is saved to historian
5.3.2. Value Deadband
5.3.2.1. ABS(Engineering Units) in order for new data point to be logged
5.3.2.2. Used to eliminate momentary small fluctuations
5.3.3. Interpolation Type
5.3.3.1. List of methods used by the historian to interpolate analog historical data
5.3.3.2. Types
5.3.3.2.1. Linear
5.3.3.2.2. Stairstep
5.3.3.2.3. Default
5.3.4. Rollover Value
5.3.4.1. Positive INT that represents a tag's reset limit when historian is operating in counter retrieval mode.
5.3.4.2. Uses rollover to calculate Delta (change)
5.3.5. Trend Hi
5.3.5.1. Initial maximum trend value in EU for clients.
5.3.5.2. Default is 100
5.3.6. Trend Lo
5.3.6.1. Initial minimum trend value in EU for clients.
5.3.6.2. Default is 0
5.3.7. Sample Count
5.3.7.1. Number of samples the historian should store in the active image for an attribute value
5.3.7.2. 0 - 9999
5.3.7.3. Historian forces value of 65
5.3.8. Enable Swinging Door
5.3.8.1. Flag that indicates whether the swinging door rate deadband is enabled or disabled.
5.3.8.2. Default is disabled
5.3.8.3. Disabled automatically for BOOL or String
5.3.9. Rate Deadband
5.3.9.1. % rate of change deadband based on the change in the slope of incoming data values to the historian.
6. Galaxy Maintenance
6.1. Exporting and Importing
6.1.1. Background
6.1.1.1. Share objects with other users in other Galaxies
6.1.2. Exporting
6.1.2.1. Only checked in versions are exported
6.1.2.2. Exports as .aaPKG
6.1.2.3. When exporting an object instance it includes parents of the object all the way up to the base
6.1.2.4. ***Scripts are NOT transferred with export and must be done separately
6.1.2.5. Can do Export all
6.1.3. Importing
6.1.3.1. Reuse from galaxy to galaxy
6.1.3.2. Import from .aaPKG
6.1.3.3. Import from .aaPDF
6.1.3.3.1. .aaPDF contains the configuration data and implementation code for one or more base templates
6.1.3.3.2. .aaPDF is created by ArchestrA Object Toolkit
6.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
6.2. Configuring Instances through a .CSV File
6.2.1. Galaxy Dump
6.2.1.1. Objects instances and their configuration data can be exported to a comma-delimited format Galaxy dump file (.csv)
6.2.1.2. Only dumps instances
6.2.1.3. Templates can NOT be dumped
6.2.1.4. Contains versions only for checked-in objects
6.2.1.5. Attributes that are locked are NOT `Saved
6.2.1.5.1. *Seems like an issue which would render this ineffective
6.3. System Management Console (SMC)
6.3.1. Background
6.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
6.3.1.2. Used to assist system integrators and system administrators in performing administrative tasks & diagnostics
6.3.1.3. Can run in a "safe mode"
6.3.1.4. Provides the ability to set Platforms and Engines OnScan or OffScan
6.3.1.5. Uses local platform as the gateway to the ArchestrA application
6.3.1.6. Does not rely on Galaxy repository to exist
6.3.1.7. Allows viewing of the layout of Galaxy repository, platforms and engines
6.3.1.8. Provides the ability to start and stop Platforms and Engines
6.3.1.9. Tools
6.3.1.9.1. VLMX Tool
6.3.1.9.2. DAServer Manager
6.3.1.9.3. LogViewer
6.3.1.9.4. Bookmarks
6.3.1.9.5. Platform Manager
6.3.1.9.6. Network Account Utility
7. Device Integration Products
7.1. Wonderware I/O Servers
7.1.1. Background
7.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
7.1.1.2. All I/O setup is done specific to the environment
7.1.2. Configuring I/O servers
7.1.2.1. Once the I/O server has been installed, some configuration is required
7.1.2.2. File named MODBUSDV.CFG stores configuration information
7.1.2.3. Configured with Modicon MODBUS - Com Port Settings
7.1.2.4. Configure definitions for PLC
7.2. Wonderware Data Access Servers
7.2.1. Background
7.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.
7.2.1.2. Uses DA Server manager
7.2.1.3. Features "Hot" configuration - ability to change dynamically while system is up and running live
7.2.2. Architecture
7.2.2.1. Three physical parts
7.2.2.1.1. 1 - Plug-in Component(s)
7.2.2.1.2. 2 - DAS Engine
7.2.2.1.3. 3 - Device Protocol Layer
7.3. Device Integration Objects
7.3.1. Background
7.3.1.1. Device Integration (DI) represent the applications networks and devices, and mirror the actual device hierarchy
7.3.1.1.1. DI Network Object
7.3.1.1.2. DI Device Object
7.3.1.2. Represent communication channels and field controllers
7.3.2. Advantages
7.3.2.1. Allow for config, deployment and monitoring of DAServers from one centralized location
7.3.2.2. Can represent all devices and PLCs in a network, enabling full plant representation and connectivity
7.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.
8. New topic
8.1. sadasdsa
8.1.1. aasdaS
8.1.1.1. ASDASDSA
8.1.1.2. asdasd
8.2. b
8.3. c
8.4. d
9. Extensions
9.1. Extendable attributes list
9.2. InputOutput Extension Group
9.3. Input Extension Group
9.4. Output Extension Group
9.5. Alarm Extension Group
9.6. History Extension Group
9.7. Boolean Extension Label
10. The Plant Model
10.1. Plant
10.1.1. Section
10.1.1.1. Area
10.1.1.1.1. Production Line
11. Planning
11.1. Application Planning
11.1.1. Project Workflow
11.1.1.1. 1 - Identify Field Devices and Functional Requirements
11.1.1.1.1. Identify all valves, agitators, rakes, pumps, PID controllers etc.
11.1.1.1.2. Start with P&ID
11.1.1.1.3. Group multiple base objects for more complex objects known as "containments"
11.1.1.1.4. Inputs / Outputs
11.1.1.1.5. Scripts needed?
11.1.1.1.6. Historization / logs?
11.1.1.1.7. Alarms?
11.1.1.1.8. Security?
11.1.1.2. 2 - Define naming conventions
11.1.1.2.1. Object.Attributes
11.1.1.3. 3 - Define the area model
11.1.1.3.1. Logical grouping within application that defines area model
11.1.1.3.2. Examples
11.1.1.3.3. Alarms grouped by area
11.1.1.3.4. Can be nested
11.1.1.4. 4 - Plan templates
11.1.1.4.1. Make Valve / Motor / Other Templaes
11.1.1.5. 5 - Define the security model
11.1.1.5.1. Who has access to what?
11.1.1.6. 6 - Define the deployment model
11.1.1.6.1. Which object instances reside on what computer?
11.2. 10 Steps for OOP Development
11.2.1. 1. Site Survery
11.2.1.1. Understand Process
11.2.1.2. P&ID
11.2.2. 2. Equipment List
11.2.2.1. Group similar pieces (Motors, valves, etc)
11.2.2.2. Identify distinct areas of operation
11.2.3. 3. Templates are configured
11.2.3.1. Each common Device
11.2.3.2. Setup Standards
11.2.3.3. Develop objects
11.2.3.4. Contain Logic, I/O, scripting, history config, security and alarms & events
11.2.4. 4. Advanced Templates
11.2.4.1. Combine other templates to make a larger object
11.2.4.2. F.E. Add level transmittor, pump, inlet/outlet valve and agitator for a single "Mixer"
11.2.5. 5. Template Attributes
11.2.5.1. Device templates have attributes which represent real I/O available in the PLC or control system.
11.2.5.2. Often Linked to the I/O through Device Integration Objects
11.2.6. 6. Application Assembly
11.2.6.1. Drag & Drop in ArchestrA IDE
11.2.6.2. Links to all template parents
11.2.6.3. Create child objects
11.2.7. 7. Object Security
11.2.7.1. Assign objects to security groups
11.2.7.2. Groups have common permissions
11.2.7.3. Roles are assigned to groups
11.2.7.4. Users can be given more than one role
11.2.8. 8. Models deployed to computers
11.2.8.1. Sent to hosts
11.2.8.2. Fully distributed system - what computer things are installed on doesn't matter as it can always and easily change
11.2.9. 9. Graphics for HMI w/ InTouch
11.2.9.1. Allows graphics to be linked to templates in ArchestrA IDE
11.2.9.2. Graphics are object oriented and tied to Plant
11.2.10. 10. Maintenance
11.2.10.1. Changes to templates to propagate to child objects
12. Package Info
12.1. ArchestrA
12.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
12.2. Galaxy
12.2.1. "...The entire application, the complete ArchestrA system consisting of a single logical namespace and a collection of WinPlatforms, AppEngines and objects
12.2.2. Galaxy Database
12.2.2.1. the relational database containing all persistent configuration information for all objects in a galaxy
12.3. Automation Information Pyramid
12.3.1. 1. Plant Floor Connectivity
12.3.2. 2. Supervisory
12.3.3. 3. Production
12.3.4. 4. Plant Intelligence
12.3.5. 5. Manufacturing Collaboration
13. Application Objects
13.1. Templates and Instances
13.1.1. Allow for reuse of existing engineering
13.1.2. Template is an entity that represents the common functional requirements of a field device.
13.1.3. Requirements reflect info such as number of inputs and outputs, alarm conditions, history needs, security etc.
13.1.4. Created from either base or derived template
13.1.4.1. Base templates can not be modified
13.1.5. Like a "cookie cutter"
13.1.6. Propagate down from highest instance
13.2. $UserDefined Object
13.2.1. Provides basic functionality you need to develop an ArchestrA supervisory applicaiton
13.2.2. Field attributes, scripts, etc.
13.2.3. As Template or Container
13.2.3.1. Template
13.2.3.1.1. Have multiple attributes specific to this type of object
13.2.3.2. Container
13.2.3.2.1. Used as a container for other objects
13.2.3.2.2. Group various objects together to make complex objects
13.3. Attribute Locking
13.3.1. Unlocked - Both templates and instances can be unlocked. Object has its own copy of the attribute value
13.3.2. Locked - Only templates can be locked. Derived objects don't have a uniqu copy of the attribute value
13.3.3. Locked in Parent - Both can be locked.
13.4. $AnalogDevice
13.4.1. Configured as basic analog device
13.4.1.1. Alarming
13.4.1.2. History
13.4.1.2.1. Can be historized
13.4.1.3. Basic I/O
13.4.1.3.1. Process Value (PV)
13.4.1.3.2. Change PV = Change Field
13.4.1.3.3. Manual Mode = no PV
13.4.1.3.4. Scaled between raw counts and engineering unit values using either Linear or Square-Root conversions
13.4.2. OR analog regulator device
13.4.2.1. External model of PID controller
13.4.2.2. Still maintain traditional alarm & history
13.4.2.3. Basic I/O
13.4.2.3.1. Reading and optionally writing two separate analog signals from the field or from another object
13.4.2.3.2. PV read from field (except in manual); NEVER written
13.4.2.3.3. SP is written and read from field
13.4.2.3.4. Scaled between raw counts and engineering unit values using either Linear or Square-Root conversions
13.4.2.4. Controller mode
13.4.2.4.1. govern types of writes are allowed to the SP value withing system
13.4.2.4.2. Manual
13.4.2.4.3. Cascade
13.4.2.4.4. None
13.4.2.5. Control tracking
13.4.2.5.1. Boolean
13.4.2.5.2. Track flag
13.4.2.5.3. Read from external device
13.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
13.4.3. Alarm Conditions
13.4.3.1. Exceeds level limt (Lo, Hi, LoLo and HiHi)
13.4.3.2. Exceeds rate of change limits for both (+) and (-)
13.4.3.3. Exceeds major and minor deviations from a target value
13.4.3.4. Has a quality value of BAD
13.5. $DiscreteDevice
13.5.1. BACKGROUND INFO
13.5.1.1. All kinds of innate statistics built in
13.5.1.2. Input output states are totally independant of each other and can be configured
13.5.1.2.1. Can be linked by alarms
13.5.1.3. State names are mapped to boolean combos in truth table
13.5.1.3.1. Off / On
13.5.1.3.2. Open / Close
13.5.1.4. 2 or more physical states
13.5.1.4.1. open
13.5.1.4.2. closed
13.5.1.4.3. moving
13.5.1.5. Represents a large collection of physical equipment common in manufacturing
13.5.1.5.1. pumps
13.5.1.5.2. valves
13.5.1.5.3. motors
13.5.1.5.4. conveyors
13.5.1.6. General purpose application object
13.5.2. STATES
13.5.2.1. Passive
13.5.2.1.1. When idle, stopped, or closed (the typical non running position
13.5.2.2. First Active
13.5.2.2.1. Represents state of the discrete device when it is considered to be running. Ex - Motor is "forward"
13.5.2.3. Second Active
13.5.2.3.1. (optional)
13.5.2.3.2. Some discrete devices have more than one active state
13.5.2.3.3. EX - Motor is "backwards"
13.5.2.4. Transition
13.5.2.4.1. (optional)
13.5.2.4.2. In transition anytime it is changing state from one valid state to another
13.5.2.4.3. EX - Valve is moving from closed to open, Off to On and is "moving" or in transition
13.5.2.5. EXAMPLE
13.5.2.5.1. Transition
13.5.2.5.2. Closed
13.5.2.5.3. Open
13.5.2.5.4. Bad
13.5.2.5.5. Where 1=TRUE and 0=FALSE
13.5.3. Alarms
13.5.3.1. Command Timeout
13.5.3.1.1. Did not change states within the specified timeout period
13.5.3.2. Un-commanded change
13.5.3.2.1. State changed when it was not commanded to do so
13.5.3.3. Individual alarms for Active1, Active2, Fault, etc.
13.5.3.4. Duration alarms for Active1, Active2, Fault, etc.
13.5.4. Statistical features
13.5.4.1. Most recent time durations for Active1, Active2, Passive, etc
13.5.4.2. Total accumulated time duration of the states Active1, Active2, Passive, etc
13.5.4.3. Total number of transitions into the Active1, Active2, Passive, etc
13.5.4.4. A command able reset of the statistics
13.6. Containment
13.6.1. Relationship in which one builds another.
13.6.2. Organize objects in a hierarchy
13.6.3. Three kinds of names
13.6.3.1. 1 - Tagnames
13.6.3.1.1. Unique name of individual object - EX - Valve1
13.6.3.2. 2 - Contained name
13.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"
13.6.3.3. 3 - Hierarchical name
13.6.3.3.1. Fully qualified names of contained object and objects that contain it
13.6.3.3.2. If "Reactor1" contains "Tank1" (also known as "SurgeTank")
13.6.3.3.3. "Tank1" contains "Valve1" (also known as "outlet")
13.6.3.3.4. Then it is
13.6.4. *Only works with derived templates
13.7. UDAs
13.7.1. Background
13.7.1.1. Set alarms and historization attributes
13.7.1.2. Set initial vales and locks on new attribute
13.7.1.3. Specify attributes
13.7.1.4. Expose Behavior
13.7.1.5. Add Logic
13.7.1.6. User Defined Attributes
13.7.2. Can add to template or an instance
13.7.3. When added to instance, locked automatically in child instances
13.7.4. When added to a template, lock state derives lock state in child object
13.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
13.7.6. MAIN AREAS
13.7.6.1. UDAs List
13.7.6.1.1. list: Lists all UDAs currently associated with the object. Click add to add a new UDA
13.7.6.2. Inherited UDAs
13.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
13.7.6.3. Data Type
13.7.6.3.1. list: Shows the data type options for configuring the selected UDA
13.7.6.4. Data types -
13.7.6.4.1. Boolean
13.7.6.4.2. Integer
13.7.6.4.3. Float
13.7.6.4.4. Double
13.7.6.4.5. String
13.7.6.4.6. Time
13.7.6.4.7. ElapsedTime
13.7.6.4.8. InternationalizedString
13.7.6.5. Categories
13.7.6.5.1. Calculated
13.7.6.5.2. Calculated retentive
13.7.6.5.3. Ojbect writable
13.7.6.5.4. User writable
13.7.6.6. Value
13.7.6.6.1. Specifies initial value
13.7.6.6.2. In the case of BOOLEAN, check box = true
14. Security
14.1. Background
14.1.1. Designed to prevent users from performing unauthorized activities
14.1.1.1. Including Users of:
14.1.1.1.1. ArchestrA IDE when configuring and deploying objects
14.1.1.1.2. The SMC (System Management Console)when performing maintenance and system administration functions
14.1.1.1.3. View (or other GUI client applications) when performing runtime operations including monitoring, control and data entry functions
14.1.1.1.4. Other future ArchestrA utilities
14.1.2. Designed to support normal operating procedures of applications
14.1.3. Not designed to stop malicious access to the system.
14.1.4. Can be configured to support OS authentication mapped to OS account(s)
14.2. Configuration Steps Overview
14.2.1. 1 - Enabling security
14.2.2. 2 - Defining security model
14.2.3. 3 - Mapping users to the security model
14.2.4. 4 - Mapping AutomationObjects to the security model
14.2.5. *** If the security is not enabled then authentication mode is disabled
14.3. Authentication Method(s)
14.3.1. None
14.3.1.1. Default for new galaxies
14.3.1.2. Considered "open security"
14.3.1.3. No authentication is provided
14.3.2. Galaxy
14.3.2.1. Uses local galaxy configuration
14.3.2.2. System controlled by galaxy configuration
14.3.3. OS User Based
14.3.3.1. Uses NT based user authentication
14.3.4. OS Group Based
14.3.4.1. Uses NT based group authentication with advanced options
14.3.4.1.1. Login TIme
14.3.4.1.2. Role Update
15. Multi-Node Applications
15.1. Application Redundancy
15.1.1. Background
15.1.1.1. Redundancy is important in processes that rely on continuous availability of information
15.1.1.2. Ensure continuous operation by providing an engine that remains active in the event of a single system compoinentfailyre
15.1.1.3. One is "active" one is "standby"
15.1.1.4. Engine --> Redundancy
15.2. DI Redundancy
15.2.1. For all intensive purposes function as "standalone objects" IE - don't have redundant "states"
15.2.2. Set to enable continuity of I/O information
15.3. Multi Node Application
15.3.1. Standalone to Network Configuration
15.3.2. Each node contains
15.3.2.1. Bootstrap
15.3.2.2. ArchestrA IDE
15.3.2.3. Galaxy Repository
15.3.3. Multi User Configuration
15.3.3.1. Setup for other nodes
15.3.3.1.1. 1 - Create Galaxy to which all other nodes will connect
15.3.3.1.2. 2 - Create platforms for other galaxy members
15.3.3.1.3. 3 - Rename the node
15.3.3.1.4. 4 - Name and deploy their own Platform as the first Platform deployed on the Galaxy