Industrial Application Server templates allow the user to rapidly create objects and deploy them into his or her environment without any substantial reconfiguration.  However, one of the major stumbling blocks developers and users have regards the automatic generation and assignment of I/O references within an object instance. By following the steps described in this article, the developer will be able to rapidly create and deploy objects without the worry of having to assign each individual point.

 

Consider the following example:

 

A pharmaceutical corporation’s cell culture building has seventeen standard bioreactors, with each bioreactor having six valves that are identical.  As a regulated system, each component’s PLC addressing follows a standard convention that is replicated over each valve.  An integrator has decided to use Industrial Application Server to create a valve template, from which he/she creates the 102 valve instances for the seventeen bioreactors. A further investigation shows that the integrator used a discrete device with two inputs, Open Limit Switch and Closed Limit Switch, and one output, the Command Out. Additionally, the integrator has created three UDAs (User Defined Attributes): One for Process Interlock, one for Fault Alarm and one for the Mode Alarm. Adding these up makes six I/O attributes that need to be assigned.  The bioreactor system utilizes more modern PLCs that have a tag-based naming convention.

 

Now, without dynamic attribute addressing, the integrator would then have to go into each one of the 102 instances and assign the DI (Device Integration) attribute reference to each I/O attribute point. While this is a perfectly valid approach, there is a much better way to do it through some simple scripting in the template. The entire configuration for dynamic attribute addressing gets placed in the template, thus removing the need to do any configuration in the instances other than changing the instance name.

 

The first step is to insert valid place holders into the attributes that will be dynamically addressed.  By default, when an attribute has or is assigned to be an I/O attribute, its reference is filled in by a standard “--.—“ by the IDE. The problem with this assignment happens upon creation of the instance.  When this particular reference is seen by the IDE, the IDE assigns the instance a warning label, as it does not recognize this as a valid address.  Because Dynamic Attribute Addressing happens at runtime, this warning will be present in the instance configuration in the IDE even after it is deployed.  To avoid this, place “---“ in the references instead.  This reference WILL evaluate as valid in configuration, and thus the IDE will not show the instance as having a warning.

 

 

 

The next thing to evaluate is what “reference attribute” holds the I/O reference for each “process attribute”.  This can be done simply by hovering the mouse over the dialog box where you would insert the I/O reference. Typically, the “reference attribute” will be the process attribute with “.InputSource” or “.OutputDest” appended to the end.  In the example below, the reference for the Input “CLS” would be “CLS.InputSource”.

 

 

Now that the “reference attributes” have been determined and assigned placeholders, the final step is to write the scripting that will assign the instances. The first step here is to create a Boolean UDA called “IsInitializing” that will be used in the script, and set the default value to True. Next, create a new script, called “AssignIO”. Select the type of the script to be “Execute”, and the trigger type to be “WhileTrue” with a trigger period of one second. This will allow the script to be triggered one second after the first scan.

 

 

 

Going back to our bioreactor example, the integrator has created a DIObject called CellCulture, with a scan group called “Bio_React”. Each valve’s I/O addressing is as follows:

 

	Open Limit Switch	<VALVENAME>.OLS
	Closed Limit Switch	<VALVENAME>.CLS
	Command out	<VALVENAME>.Cmd
	Process Interlock	<VALVENAME>.Intlk
	Fault Alarm	<VALVENAME>.Fault_alm
	Mode Alarm	<VALVENAME>.Mode_alm

 

Hence, the I/O reference address for the Open Limit Switch of CV101 would be “CellCulture.Bio_React.CV101.OLS”, the Closed Limit Switch “CellCulture.Bio_React.CV101.CLS”, and so on.

 

The objective of the script, then, is to build the above references as strings, then assign them to the “reference attributes” in the instance.  In each reference, the only “dynamic” part in this case would be where the name of the valve is. Hence, the rest can be entered as a string in the script and concatenated with the tagname using the “me.tagname” attribute in the proper place where the valve name should be.  The resulting line of code would look like this:

 

me.OLS.InputSource =  "CellCulture.Bio_React." + me.tagname + ".OLS";

 

This can then be repeated for each of the remainder of the references. At the end of the AssignIO script body, reset the IsInitializing bit to zero to stop the script. Below is the final script for the valve.

 

 

This method of dynamic referencing can be tailored to the needs of the end user as well.  For example, consider the case of each bioreactor having separate PLCs connected by an Ethernet backbone.  In this case, there would not be one, but seventeen DIObjects and Device Groups that the script would need to decide upon.  This can be fixed by separating each set of instances into separate areas, and putting a string UDA in the Area, which will store the path to the DIObject and Device Group. 

 

For example, the integrator calls each Bioreactor’s DIObject “PLC_BRxx”, where “xx” is the number of the bioreactor, and he calls all of the topics “BR”. He then creates a UDA in each of his areas called “DIPath”.  In this model, the string to store in the UDAs would be “PLC_BRxx.BR.”, and the script line would look like the example below:

 

me.OLS.InputSource = mycontainer.DIPath + me.tagname + ".OLS";

 

Now, while this is great for PLCs that support advanced naming structures, what about PLC systems that do not?  In this case, one can still take advantage of dynamic attribute addressing by creating an alias list in the DIObject.  Each DIObject has a section for an alias list, which allows the user to map PLC register addresses to more structured naming conventions.  By utilizing the alias map in the DIObject, a user is then able to enjoy the advantages of dynamic attribute addressing.

 

 

By using scripting and Industrial Application Server’s built-in relational referencing, the end user can create templates whose instances automatically build their I/O reference.  This will greatly reduce development time across a user’s galaxy, and can be used even in the case of the PLC that does not support an advanced naming structure.  Thus, Dynamic Attribute Addressing can be a vital tool to any Industrial Application Server user.