OVERVIEW

An Object Wizard can be added to any derived template to provide a simplified user interface for configuring instances (assets) derived from the template. When configuring an instance derived from a template with Object Wizards, it may have a series of user selectable Choices and Options that guide you through the process of the configuration. Each Choice and Option may have one or more attributes, symbols, and/or scripts associated with it.

Object Wizards can integrate a wide variety of configuration possibilities, which can reduce many levels of the template derivation hierarchy. The result is fewer templates to manage and a simpler process to create and configure instances.

APPLIES TO:

• AVEVA Application Server 2017 and later

EXPLANATION

There are different ways of modeling templates, including building super objects with all possible attributes, symbols, and scripts within one template, using multiple derivations to add necessary attributes, symbols, and scripts to each level of derived template, and creating Object Wizards.

The following tables compare building super objects and multiple derivations to using Object Wizards. As examples, the comparisons are based on building templates with attributes only.

Building Super Objects	Using Object Wizards
Add all possible attributes to templates	Add all possible attributes to templates
All derived objects have all attributes	Derived objects only include necessary attributes as determined by Object Wizard configuration
All attributes deployed to runtime	Only necessary attributes deployed to runtime

 

Using Multiple Derivations	Using Object Wizards
Add common attributes to first-level template	Add all possible attributes to templates
Add attributes and features to each derived object to meet requirements	Attributes and features are determined by the Object Wizard configuration for each derived object
More levels of derivation, harder to maintain	Reduced levels of derivation, easier to maintain

Wizard Options

The Object Wizard presents a series of prompts and questions, from which you can select answers to build an instance as needed. For example, you might be building an instance that represents a piece of field equipment, such as a pump, motor, or valve. You can configure the instance by selecting an answer for each prompt or question listed in the Wizard Options panes.

An Object Wizard can have Choice Groups and Options. A Choice Group is presented with a drop- down list of two or more responses (Choices), from which you can select a response. An Option is presented as a check box that can be checked (true or on) or unchecked (false or off).

Along with configuring each available Wizard Option by selecting a Choice of a Choice Group or checking the check box of an Option, the associated attributes, symbols, and/or scripts can be set to be available or not for the instance.

Additionally, based on the configured Wizard Options, the settings of an attribute or a symbol might be configured as well. For example, checking an Option might enable the History feature for the associated attribute or the value of a custom property might be set to a new value.

IMPLEMENTATION

For our example, we will add Object Wizard options to a pre-built Counter object which already has all the attributes, scripts and symbols for three different counter variations built into it.

You can download a copy of the aaPKG file and import it into your galaxy from here ($Counter.zip).

Add and Configure a Choice Group

1. Launch the IDE.  In the Template Toolbox \ Training \ Project toolset, double-click the $Counter template to open its configuration editor.NOTE: If the Choices and Options and Settings panes are not visible, click the Configure Wizard Options button located above the Attributes pane.

2. In the Attributes tab, Choices and Options pane, click Add ChoiceGroup.
   
   A Choice Group with two Choices is added in the Choices and Options pane. By default, the Choice Group Prompt is Group #1 and the Choices are Choice #1 and Choice #2. You will add another Choice in the next step.Notice that the Prompt, Description, and Visibility fields appear at the bottom of the Choices and Options pane. These fields can be used to configure the Choice Group, Choices, and Options.
   

3. In the Choices and Options pane, click the Add Choice button to add another Choice for the Choice Group.
   
   A new Choice named Choice #3 is added to Group #1.
   

4. In the Choices and Options pane, select Group #1.
   

5. In Prompt, enter the prompt for the group as Counter Type and press Enter.
   The Group #1 prompt changes to Counter Type.

6. In Description, enter Select the type of counter and press Enter.Descriptions are used as tooltips for the settings.
   

7. Repeat steps 5 & 6 to configure prompts and descriptions for the Choices:
   

   Default Prompt	New Prompt	Description
   Choice #1	Scan	Counter is triggered every scan
   Choice #2	Trigger	Counter is triggered when the Trigger attribute is set to True
   Choice #3	Input	Counter is triggered when the data changes in the Value attribute

Associate Attributes, Scripts, and Symbols to Choices

Now you will associate attributes, scripts, and symbols to the Scan, Trigger, and Input Choices.

8. In the Choices and Options pane, select the Scan Choice.

9. If the Scripts pane is not visible, you will need to show Click the Show Scripts button just above the Attributes pane.
   
   The Scripts pane appears below the Symbols pane. If needed, resize the Scripts pane to see the scripts.

10. In the Scripts pane, select the CountByScan script and drag it into the AssociationsNote: For the Scan type, the counter is triggered by the AppEngine’s scan period.  It is not triggered by a specific attribute, so no attributes need to be associated with this choice.

11. In the Symbols pane, select CounterDisplay and drag it to the Associations

12. In Associations, ensure CounterDisplay is selected.

13. In Settings, from the drop-down list for CounterType, select Scan.
    By associating the symbol to the Choice, it is possible to override the default settings of the symbol’s properties when that choice is selected.Notice that the visibility of the CounterType setting is automatically set to hidden, as reflected in the Visible icon for the setting. When an instance is set to count by scan, the symbol will be set to Scan automatically and will not be changeable when it is embedded in another symbol, because the setting has been set to hidden.

14. In the Choice and Options, select the Trigger Choice.

15. In Attributes, select the Trigger attribute and drag it to the Associations pane.

16. In the Scripts pane, select CountByTrigger and drag to the Associations pane.

17. In the Symbols pane, select CounterDisplay and drag it to the Associations pane.
    

18. In Associations, make sure CounterDisplay is selected.

19. In Settings, set CounterType to Trigger.
    

20. In Choices and Options, select the Input Choice.

21. In Attributes, select the Value attribute and drag it to the Associations pane.

22. In Scripts, select CountByInput and drag it to the Associations pane.

23. In Symbols, select CounterDisplay and drag it to the Associations pane.

24. In Associations, make sure CounterDisplay is selected.

25. In Settings, set CounterType to Input.
    

Add and Configure an Option

Now you will add an Option to show a reset button for the counter.

26. In Choices and Options, click the Add Option button.
    
    An option named Option #1 is added.
    

27. With Option #1 selected, configure the option as follows:
    

    Prompt:	Has Reset Command
    Description:	Check to include a reset control for the counter

28. In Attributes, select ResetCmd and drag it to Associations.

29. In Scripts, select ResetCounts and drag it to Associations.

30. In Symbols, select CounterDisplay and rag it to Associations.

31. With CounterDisplay selected, in Settings set ShowReset to True.
    

Test the Configuration

Finally, you will test what you have built.

32. In Choice and Options, click the Test button.
    
    The display changes to testing mode.
    

33. In Choices and Options, select a different Counter Type and check and uncheck Has Reset Command to see the behaviors.For example, if you check Has Reset Command, you can see the ResetCmd attribute in Attributes list, a Reset button appears on the CounterDisplay symbol in the Symbols pane, and a ResetCounts script in the list of scripts.

34. Click the Test button again to exit testing mode.

The post Introduction to Object Wizards appeared first on Industrial Software Solutions.

This training document provides an overview of I/O Auto-Assignment in AVEVA Application Server. It explains how the I/O feature allows configuration of data input and output for attributes, along with advanced properties. I/O Auto-Assignment eliminates the need for manual configuration or scripting of I/O references, streamlining the deployment process.

This document assumes understanding of Device Integration (DI) Objects and OI-Servers.

APPLIES TO

• Application Server

EXPLANATION

The I/O Feature

The I/O feature can be applied to attributes in application objects to enable the configuration of data input and output for attributes.

The feature allows specifying I/O types such as:

• Read (Input)
• Read/Write (Input/Output)
• Write (Output)

Advanced I/O properties are available based on the attribute’s data type and I/O type.

I/O Auto Assignment

I/O Auto Assignment is a time-saving alternative to manually configuring I/O references or scripting them at runtime. By enabling I/O Auto Assignment, you can prepare input or output attributes for automatic assignment, eliminating the need to edit individual objects for I/O configuration and reduce cumbersome scripting for setting I/O. When using auto-assignment, your object name format must follow the same syntax as the actual item in the PLC.

NOTE: I/O Auto Assignment is the default setting for application and other system objects like area objects, but Device Integration (DI) Objects still must be manually configured.

When input or output attributes are added to an area or application object in the Object Editor’s Attributes tab, the default setting prepares these attributes for I/O Auto Assignment. The auto assignment reference appears in the I/O section of the Attributes tab when the I/O attribute feature is enabled.

The default string for an input reference is:

IODevice.[ObjectName].[AttributeName].InputSource

For an output reference:

IODevice.[ObjectName].[AttributeName].OutputDest.

Where IODevice is a placeholder for automatically building the I/O reference when the object is linked to a scan group and DI object, without manual entry or scripting.

For instance, the reference <IODevice>.Mixer.Tank.Inlet.InputSource is transformed to OPC001.Fast.Mixer.Tank.Inlet.InputSource after assigning the object to the scan group “Fast” under DI object “OPC001.”

NOTE: Do not lock InputSource or OutputDest attributes when using I/O Auto Assignment, as locking these attributes in the parent template will prevent the resolved reference from updating during object deployment.

Validating I/O Assignments and References

The IO Device Mapping view displays I/O Auto Assignment references for application and system objects linked to DI object scan groups. Manually configured references are not shown, nor are attributes associated with objects not yet assigned to a scan group.

In the IO Device Mapping view, you can view and validate I/O references for each auto-assigned attribute and override the generated references. You can also select multiple items, filter, sort, or group the attributes as needed. The view also is divided into columns displaying information for each auto-assigned I/O attribute. You can customize the display by sorting, grouping, or filtering the attributes.

To ensure the accuracy of I/O assignments without needing to check out objects, you can validate auto-assigned I/O attributes in the IO Device Mapping view by pressing the “Validate References” button.

IMPLEMENTATION

Optional Section – Configuring a DI Object for Data Simulation

This section will walk you through configuring the OI-Simulator (OI.Sim), which we will use in this training document. This document assumes the OI-Server, OI.Sim, is installed on the same computer as the GR node/where these objects are being deployed. Any references to “server node” will use “localhost”.

If you already have a designated DI Object, you can jump to Configuring I/O Auto-Assignment.

1. In the IDE, create a new instance of $OPCClient from Template Toolbox -> Device Integration. Name the instance “Simulator“

NOTE: “Simulator” is the required name in order for this object to connect to the OI-Simulator.

2. Double-click “Simulator” to open its configuration editor. On the General tab, enter “localhost” for the Server node and choose “OI.SIM.1” for the Server name.

3. On the “Scan Group” tab, add three scan groups with the following configuration:

4. Save and close the editor.

5. Assign “Simulator” to an app engine for deployment.

6. Right-click “Simulator” -> Deploy with the default options. Deploy the platform and app engine before doing so.

7. Once deployed, navigate to the SMC and verify that the OI.Sim driver has started. The driver will auto-start once an $OPCClient instance named “Simulator” is deployed.

Configuring I/O Auto-Assignment

1. To begin, create an instance of $UserDefined. Name the instance “Test”.

2. Open “Test for editing. Add a new attribute configured as follows:

Name: PV

Description: Test PV value

Data Type: Float

Writeability: Object writeable

Initial Value: 0.0

Features: I/O

3. Note when you enable I/O, the Read from/Write to field automatically populates with: Simulator.Fast.Test.PV

This is because objects with I/O enabled use auto-assignment by default. This means that at runtime, Test.PV will resolves it’s I/O source through the “Fast” topic on the Simulator DIObject.

NOTE: Since we are using the Simulator, our reference can be anything. In practice, you’d need to ensure your object naming convention lines up with the item syntax from the PLC in order to successfully  use I/O Auto-Assignment.

4. Assign “Test” to an $Area instance hosted on an app engine and platform and deploy.

5. Right-click “Test” -> View in Object Viewer. Add “PV” to the Watch Window and observe the value change.

6. You can also assign objects to other I/O devices easily. In IDE go the View menu -> IO Devices to show the IO Devices pane. Expand Simulator -> Fast and observe that “Test” is assigned here.

7. Undeploy “Test”. Then, in IO Devices, move “Test” to the “Normal” device group by dragging and dropping. Then, open up “Test” for editing. Observe that the I/O feature for the PV attribute has been revised to: Simulator.Normal.Test.PV

The post I/O Auto Assignment Overview appeared first on Industrial Software Solutions.

This training document provides an introduction to application objects in AVEVA Application Server. It explains the concept of application objects, their types, and their configuration options. The document also covers the implementation steps, including creating object templates and instances. This training document will walk you through implementing:

• Creating and deriving templates and instances
• Configuring attributes

APPLIES TO

• Application Server (all versions)

EXPLANATION

Application Object Overview

Application Server is designed as an Object-Oriented Application, where objects play a fundamental role. Application objects can be configured to do a number of things. Application Server provides the following objects:

AnalogDevice Object

The AnalogDevice object can function as a basic analog input device with optional output or as an analog regulator device representing a Proportional-Integral-Derivative (PID) controller from external sources such as PLCs or DCSs.

DiscreteDevice Object

The DiscreteDevice object represents common physical equipment in manufacturing, such as pumps, valves, motors, and conveyors. It monitors and controls devices with discrete physical states through discrete inputs and outputs.

Sequencer Object

The Sequencer object allows configuration, execution, and manipulation of a sequence of operations associated with ArchestrA attributes. It is used for automating manufacturing procedures or supervisory processes with a finite number of steps.

SQLData Object

The SQLData object provides an interface to a Microsoft SQL Server. It can connect to an existing SQL Server database table or create a new database and tables.

UserDefined Object

The UserDefined object is a versatile object that provides configurable attributes, scripts, and graphics. It serves as a template for creating customized objects. This object will be used in the Implementation section of this training document.

System Objects

• $AppEngine: The runtime engine responsible for executing scripts, handling events, and coordinating communication within the galaxy.
• $Area: Used for organizing objects within a galaxy based on functional areas or physical locations, providing structure and easier management.
• $InTouchViewApp: For creating and configuring InTouch HMI applications.
• $ViewApp: For creating and configuring OMI applications.
• $ViewEngine: The engine responsible for executing InTouch View applications, handling the runtime execution of graphics, scripts, and data interactions.
• $WinPlatform: The logical representation of physical computers/PCs in the plant/system, providing configuration settings and properties specific to Windows-based systems.

Device Integration Objects

• $DDESuiteLinkClient: The object used to connect galaxy attributes to live data via 3rd party DDE Servers and AVEVA I/O Servers using DDE and SuiteLink protocols.
• $InTouchProxy: Acts as a gateway between Galaxy application objects and tag data from an InTouch application.
• $OPCClient: The object used to connect galaxy attributes to live data via third-party OPC Servers using OPC protocol.
• $RedundantDIObject: Provides the ability to configure a single object with connections to two data sources and allows failover functionality.

Templates and Instances

When configuring objects, you can either create a Template or an Instance. Templates and instances have a parent-child relationship. Templates act as the parent objects that define the common properties and behaviors, while instances are the child objects that inherit those properties and can be customized further. Modifying a template affects all its derived instances, providing a convenient way to make global changes.

Templates

Object templates serve as a blueprint or a predefined configuration for creating multiple instances of the same object type. Templates define the structure, attributes, features, and behaviors that are common to all instances derived from them. Templates allow for consistency and ease of object creation. Templates are identified with the “$” at the front of their name.

The built-in object templates cannot be modified, but you can create a derived template from the built-in templates for further customization. The orange padlock icon indicates that an object is a non-editable template.

Instances

Instances are the individual objects created based on object templates. Each instance is a unique object with its own set of attributes and configurations. Instances inherit the structure and attributes from their corresponding templates, but can be customized to meet specific requirements. You can only assign and deploy object instances to platform/app engine/area objects.

Attributes

Attributes are the characteristics or properties of application objects. They represent the data associated with an object and define its behavior and functionality. Attributes can store values of various data types, such as Boolean, Integer, Float, Double, String, Time, and more.

Attribute names must follow certain conventions:

• Attribute names can have up to 32 alphanumeric characters, including periods.
• Attribute names must include at least one letter.
• Attributes starting with an underscore (_) as the first character are considered hidden and are not visible in Attribute Browser or Properties dialog boxes.
• Using the word “quality” as an attribute name is not supported due to a naming conflict.

Attribute Features

• I/O: Configuring input and output sources for an attribute.
• History: Logging attribute values for historical analysis.
• Limit Alarms: Setting threshold limits for triggering alarms.
• ROC (Rate of Change) Alarms: Monitoring the rate of change in attribute values.
• Deviation Alarms: Detecting deviations from target values.
• State Alarms: Defining alarm conditions based on the state of a Boolean attribute.
• Bad Value Alarms: Raising alarms when an attribute has invalid or bad data.
• Statistics: Calculating statistical information for attribute values.
• Log Change: Logging data change events for an attribute.

By enabling these features, attributes can provide advanced functionality and facilitate efficient monitoring and control within the application.

Attribute Data Types

• Boolean
• Integer
• Float
• Double
• String
• Time
• ElapsedTime
• InternationalizedString

Object Icons

In the Model, Deployment, Derivation, and IO Devices views, objects are listed in a tree structure that functions like a standard Microsoft Windows Explorer tree. Under each branch of the tree, objects are listed in alphabetical order. Default objects are shown in bold.

For objects shown in any view, icons to the left of the object name are used to show object deployment status, error/warning conditions, checked-in status, or object wizard status.

IMPLEMENTATION

Section 1 – Create a Derived Template and Instances

In this section, we will create a derived template from $UserDefined to represent a Tank object. Then, we will derive 3 “Tank” instances.

1. In the IDE, go to the Template Toolbox, and navigate to <GalaxyName> -> Application. Locate the $UserDefined object and right-click -> New -> Derived Template.

2. The Derived Template appears. Name the template “Tank”.

NOTE: The “$” will be added automatically to template names.

3. Right-click $Tank -> New -> Instance to create a child object. This is one method for creating instances.

4. Notice the object instance appears in the Model, Deployment, or Derivation view, not in the Template Toolbox. The Model view is a logical organization of objects based on their physical location in the plant or system. The Deployment view is where object instances must be assigned and deployed. In the Deployment or Model view, it will appear under the Unassigned Host folder by default. In the Derivation view, it will appear showing under $Tank to indicate this instance was derived from $Tank, which was derived from $UserDefined. Name this instance “Tank1”.

5. Navigate back to Template Toolbox and select $Tank. Drag-and-drop $Tank into the Model, Deployment, or Derivation view. This is another way to create an instance. Name this instance “Tank2”.

6. Lastly, navigate back to Template Toolbox and select $Tank. Use the keyboard shortcut ctrl + N to create a third instance, named “Tank3”.

7. Assign the instances in Deployment View for deployment. Instances must be assigned to an $Area instance which represent logical organization of different objects in your plant or system. $Area instances must be assigned to an $AppEngine instance, which host and schedule execution of Application Objects. $AppEngine instances are assigned to $WinPlatform instances, which represent the physical computers in your plant or system.

You can assign instances by right-clicking them -> Assign To, or by dragging and dropping them to a particular $Area instance.

Section 2 – Configure Attributes

In this section, we will add some attributes to our $Tank derived template and enable some attribute features.

1. Open the $Tank derived template created in steps 1 and 2 of the Create a Derived Template and Instances section by double-clicking the object. The object editor appears.

2. In the Attributes area, click the + button to create a new attribute. The attribute editor opens.

3. Enter the following information:

Name: Pump1_Status

Description: Monitors if the pump is Open (True) or Closed (False).

Data Type: Boolean

False/True Label: Closed/Open

Writeability: Object Writeable

Initial Value: Closed

4. Enable the I/O Feature and State Alarm feature. Leave the settings as default.

5. Save and close $Tank. Observe the Check-In warning regarding propagation. Click OK.

6. Now, open one of the $Tank instances, such as Tank1. Observe that the Pump1_Status attribute has been added. This is because we added an attribute from the parent template level and therefore propagated to the child instances. The name shows [$Tank] to indicate where the attribute is derived from.

7. You will also observe that the instance objects have a warning icon over them. That is because, for the purposes of this document, we did not configure a valid I/O location. In practice, you would make sure to configure Device Integration objects and provide a valid I/O reference for I/O features in the form of <IODevice>.<TopicName>.<ItemReference> or use I/O Auto-Assignment, which is outside the scope of this document. For a full list of object icons, see Object Icons.

8. Add a new attribute to Tank1, configured with the following:

Name: Level

Description: Real value showing the current water level of the tank

Data Type: Float

Writeability: Object writeable

Initial Value: 0.0

Eng units: mL

I/O Feature: Enabled

9. Save and close Tank1. Click “Yes” to acknowledge the warning about I/O. Open Tank2 and observe that the Level attribute does not exist here. That is because we created that attribute at the instance-level just for Tank1, but Pump1_Status does appear because it comes from the $Tank derived template.

The post Introduction to Application Objects appeared first on Industrial Software Solutions.

Data acquisition redundancy allows high availability of external I/O data through use of a Redundant DI Object (Device Integration Object) that monitors and controls its’ respective primary and backup data sources.  This training document explains how to configure and deploy RedundantDIObjects, or RDIOs, for enabling redundant connections to field devices in Application Server.

This documents assumes understanding of application objects and DIObjects (DDESuiteLinkClient or OPCClient), as well as OI-Servers. For more information on configure a DDESuiteLinkClient object, please see ISS Tech Note 76.

For more information on Application Server redundancy and load-balancing in general, please see ISS Tech Note 109.

APPLIES TO

• Application Server (all versions)

EXPLANATION

Data Acquisition Redundancy provides the ability to monitor and control redundant DIObject data sources. It allows for redundant connections to field devices.

Configuration

To enable data acquisition redundancy, you will create and configure the following components:

• Primary DIObject
• Backup DIObject
• Redundant DIObject

Both DIObject data sources must have the same item address space and commonly-configured OI-Server device groups/topics. In your RDIO, designate one DIObject as the Primary source and the other as the Backup source. The RDIO checks the state of its source DIObjects on every scan cycle. If a valid ping is not received for the Primary DIObject, the RDIO will switch to pull data from the Backup source. A failover can also be forced if needed.

RedundantDIObject Behavior

The RedundantDIObject supports the following operations on I/O points from field devices:

• Subscriptions via scan groups
• Read transactions via block reads (when available)
• Write transactions via block writes (when available) (NOTE: The RDIO queues and writes all data received in a scan cycle.)

During runtime, the RDIO monitors the status of its DIObject data sources and handles switching from Active to Standby object if failure conditions occur. The terms “Active” and “Standby” apply to the configured Primary and Backup objects. RDIOs monitor PLC connectivity using the scan group PingItem attribute. It will regularly try to advise this item from the PLC using either it’s primary or backup data source. If it does not receive a response, the RDIO will show a status of “Disconnected”.

NOTE: It is recommended to manually configure a PingItem attribute for each scan group – this PingItem should be a consistently changing item in the PLC

IMPLEMENTATION

NOTE: For the purposes of this document, our objects will all be hosted on a single platform and app engine. The document assumes a platform and engine and have already been created. In order to achieve true redundancy in an environment, you would configure two redundant platforms. Each platform would have their own “I/O” App Engine, and then a single redundant AppEngine would be configured. The primary and backup DIObjects would be hosted on the respective I/O engines on each platform, and the RDIO would be hosted on the redundant engine.

1. To start, create two DIObjects to act as our primary and backup data sources. In this document, we will create DDESuiteLinkClient objects that connect to OI-MBTCP. Name the DIObjects MBTCP_Primary and MBTCP_Backup respectively. Besides the “Server node”, their configuration details should be the same. Below has an example of a potential configuration:

MBTCP_Primary

MBTCP_Backup

2. In the Template Toolbox -> Device Integration -> right-click $RedundantDIObject and create a new instance named “MBTCP_RDIO”.

3. Double-click “MBTCP_RDIO” for editing. From the dropdown menu, choose “MBTCP_Primary” for the Primary DI Source and “MBTCP_Backup” for the Backup DI Source.

4. Click the Scan Group tab and click the Copy Common Scan Groups button. The “Copy Common Scan Groups” window appears.

5. This pop-up will identify any matching device group/topic names and list them in the Identically named area. Click OK to load in the common scan group(s).

6. Configure a valid Ping Item. This should be a frequently changing item directly from the PLC. Once finished, click “save and close”.

7. The objects can now be assigned and deployed to app engines. Once the objects are deployed, the following RDIO attributes are useful for monitoring status in Object Viewer:

• ConnectionStatus: Indicates the current connection status of the RDIO, reflecting whether it is connected or disconnected to its data sources.
• DISourceActive: Identifies the currently active DIObject data source within the RDIO, specifying the source providing the field device data.
• DISourceBackup: Represents the backup DIObject data source within the RDIO, serving as a standby in case of a failure in the active data source.
• DISourcePrimary: Designates the primary DIObject data source within the RDIO, defining the initially configured active source before any switching occurs.
• DISourceStandby: Signifies the standby DIObject data source within the RDIO, representing the initially configured backup source before any switching takes place.
• ForceFailoverCmd: Allows for a manual command to force a failover, enabling a deliberate switch from the active source to the backup source.
• StatusBackupDISource: Indicates the status of the backup DIObject data source, providing information about its current state, including connection status or error conditions.
• StatusPrimaryDISource: Represents the status of the primary DIObject data source, offering information about its current state, such as connection status or encountered errors.
• SwitchCnt: Keeps track of the number of switches that have occurred between the active and standby DIObject data sources, incrementing each time a switch occurs.
• SwitchReason: Provides information about the reason behind a switch from the active to the standby DIObject data source, indicating factors such as a connection failure or communication error.

These attributes play essential roles in monitoring, managing, and controlling the behavior of the RDIO and its data sources within the system.

The post Device Integration Redundancy Configuration appeared first on Industrial Software Solutions.

When developing in Application Server, you may find it useful or necessary at a point to share objects or recreate them in other Galaxies. To accomplish this, you can use the IDE’s export/import functions. When you perform an export, the resulting .aaPKG file includes the selected objects, associated templates, and their configuration state.  The exported file can be later imported into the same or another Galaxy.

If any of the selected objects are checked out, only the checked-in versions will be exported. Exporting an entire Galaxy is similar to using the Galaxy Database Manager utility for backup, but it doesn’t export object change logs or retain security model settings. When exporting an object instance, it will include all its parent objects, including the base template.

This training document will walk you through how the IDE to:

• Export automation objects
• Import automation objects

APPLIES TO

• Application Server

EXPLANATION

Considerations for Export and Import

To reuse objects from another Galaxy in your own, you can export and import them, which saves time if the objects are already configured in another Galaxy. When importing instances that were previously exported from a Galaxy, the import process tries to maintain previous associations such as assignment, containment, derivation, and area. You can import objects from either exported .aaPKG files or from an .aaPDF file. An .aaPDF file contains configuration data and implementation code for one or more base templates and is created using the ArchestrA Object Toolkit by a developer, which is an optional software.

Before importing, it’s important to note that you cannot have two objects with the same name or more than one copy of the same object version in the same Galaxy. During the import process, any conflicts with existing objects will be identified, and you will have the ability to manage and resolve them.

You can also choose to export objects as “Protected Objects” from the Galaxy -> Export menu. This prevents the object from being edited or overwritten.

IMPLEMENTATION

Section 1 – Export Objects

1. In the IDE, select the object or objects you wish to export. Then on the Galaxy menu, select Export -> Objects.

2. The Export Automation Object(s) dialog box appears. In the dialog box, browse to a path of your choice and name the export file.

3. Click Save. The Export begins. When the export process finishes, click Close.

4. Click Close and navigate to the path designated for the export to find the resulting .aapkg file. This file can be used to import the chosen objects into another galaxy.

Section 2 – Import Objects

1. In the IDE, open the Galaxy menu, select Import-> Objects.

2. The Import AutomationObject(s) dialog box appears. Navigate to the desired .aapkg or .aapdf file and click Open.

3. The Import Preferences dialog box appears. The following options can be configured:

Objects with same Tagname and Codebase as an existing object

• Skip: Do not import: Leaves the existing object unchanged.
• Overwrite existing objects if the imported configuration version is higher: The default setting. Replaces the existing object with the object being imported if the imported object has a newer configuration.
• Overwrite objects regardless of configuration version: Replaces the existing object regardless of whether the existing object has an older configuration or the same configuration.

Base Templates with a different revision number in the Codebase or a different minor version

• Skip: Do not migrate: Does not migrate objects with an older Codebase when a newer Codebase exists in the Galaxy.
• Migrate: The default setting. migrates an older codebase when the replacement object is available.

Objects with same Tagname but with a different Codebase

• Skip: Do not import: The default setting. Leaves the existing object unchanged.
• Rename object in Galaxy: Imports an object with a matching tagname but a different codebase from the existing one. The existing object is not overwritten but is renamed.
• Rename importing object: Imports an object with a matching tagname but a different codebase from the existing one. The existing object is not overwritten. The imported object is renamed.

4. Click OK to start the import process. When the import process is complete, you can start using the objects you imported.

Imported templates are listed in the proper toolset in the Template Toolset as defined in the object. Imported instances are shown in the Application views.

The following post-import rules apply:

• If a toolset does not exist, it is created.
• If the object belongs to a security group that does not exist, it is associated with the Default security group.
• If the object belongs to an area that does not exist, it is associated with the Unassigned Area.
• If the host to which the object is assigned does not exist, it is assigned to the Unassigned Host.
• If you selected Migrate from the Import Preferences dialog box, the migrated objects are marked with “software upgrade required” if they are deployed. These objects will be upgraded when the objects are redeployed.

The post Importing and Exporting System Platform Objects appeared first on Industrial Software Solutions.

When you create a galaxy in the IDE, a Galaxy Repository (GR) is created, which is a series of files, folders, and a database that contains all the configuration data and object deployment states for that particular galaxy. In order to backup, restore, or migrate a galaxy, you must use the Galaxy Database Manager to create a cabinet (.CAB) file for the galaxy. This training document will explain how to:

• Use the Galaxy Database Manager to backup and restore a galaxy on the same computer
• How to restore and/or migrate a galaxy to another computer using the BackupGalaxies folder

APPLIES TO

• Application Server

EXPLANATION

Galaxy Database Manager

In the System Platform Management Console (SMC) or Operations Control Management Console (OCMC), a console item exists on the Galaxy Repository computer called the Galaxy Database Manager. The Galaxy Database Manager backs up and restores a Galaxy.

Backing up a Galaxy creates a single .CAB file containing all the necessary files, configuration data, and object deployment states to recreate the Galaxy in an empty Galaxy Repository. No write operations are allowed during backup. If there is write activity, it’s advisable to back up at a later time. Restoring a Galaxy utilizes the backup file to overwrite an existing Galaxy or create the backed up Galaxy in a different Galaxy Repository. Confirmation is required before overwriting a Galaxy during the restore process.

You can perform the Backup action within this utility or the Restore action.

BackupGalaxies Folder

In a situation where you want to create a new galaxy from the .CAB file, you would not use the Restore method from the Galaxy Database Manager. Instead, you would first copy the backup file to C:\Program Files (x86)\ArchestrA\Framework\Bin\BackupGalaxies. Then, from the IDE, you can create a “New Galaxy” using this .CAB file as the “Galaxy Type”. This method would be used if you were taking a .CAB file backup and moving it to a new computer, or during a migration to a newer version.

IMPLEMENTATION

NOTE: Before you are able to restore a galaxy using either the Galaxy Database Manager or the BackupGalaxies folder, you must have a .CAB file backup. Section 1 has the instructions for how to backup the galaxy.

Section 1 – Use Galaxy Database Manager to Backup a Galaxy

1. On the GR computer, open the SMC/OCMC and locate the Galaxy Database Manager. Find and select your desired galaxy.

2. Right-click the desired galaxy and select Backup.

3. The Galaxy Database Manager window appears. Verify and acknowledge that there are no applications writing to the GR node by clicking Yes.

4. Choose a location and file name for the galaxy backup. Then click Save.

5. The backup process begins. Observe the messages in the Galaxy Database Manager window and ensure that the backup completes successfully. Then click Close.

6. You can now navigate to the path designated in Step 4 and find the newly created .CAB file.

Section 2 – Use Galaxy Database Manager to Restore a Galaxy

1. On the GR computer, open the SMC/OCMC and locate the Galaxy Database Manager. Find and select your desired galaxy.

2. Right-click the galaxy and select Restore.

3. Verify and acknowledge that no applications are using the GR node, follow the recommendations, and acknowledge that the galaxy to be restored will be overwritten during this operation. Click Yes when ready to continue.

4. Navigate to the location where the desired backup .CAB file to restore from is stored. Then click Open.

5. The restore process begins. Observe the messages in the Galaxy Database Manager window and ensure that the restore completes successfully. Then click Close.

Section 3 – Move/Migrate a Galaxy by Creating a New Galaxy From a Backup .CAB File

If you have a galaxy that you want to move to a new computer, or that you want to migrate to a new version, the following process must be utilized.

1. Open Windows File Explorer and navigate to C:\Program Files (x86)\ArchestrA\Framework\Bin\BackupGalaxies

2. Copy/paste your desired backup .CAB file to the BackupGalaxies folder.

3. Open the System Platform IDE under Windows Start -> AVEVA System Platform. The Connect to Galaxy window appears.

4. Click New Galaxy. The “New Galaxy” window appears.

5. Type in your desired galaxy name. Then from the Galaxy type drop-down, find the new Galaxy type named after the .CAB file that was placed in BackupGalaxies in step 2.

6. Click Create. Observe the messages in the Galaxy Database Manager window and ensure that the galaxy creation completes successfully. Then click Close.

7. If this is a migration to a new version, you must connect to the new Galaxy after creation. Then a prompt for migration will appear. This only needs to be done once.

The post Backup, Restore, and Migrate a Galaxy Database appeared first on Industrial Software Solutions.