When modeling a production process, it may happen that a certain property is not built into the software: the material of the equipment, or the packaging type of an order. This can easily be resolved with Custom Attributes. However, the possibilities of custom attributes exceed the simple assignment of simple strings or numbers by far: Did you know that you can also store entire objects, e.g., a table object, in a custom attribute? This tip & trick gives an overview of the different types and use cases of custom attributes.
Standard Use Case of Custom Attributes
Custom Attributes (CAs) can be used to assign additional properties to INOSIM objects that are not otherwise available in the software. By default, CAs can be created and edited via the software interface (e.g., in order to store the material of the equipment in the Units dialog). During the simulation, the created values are always applied via VBA. Custom attributes are generally created for all items of an object category, e.g., all units have the CA Material, even those for which the value is not needed in the simulation. For the following categories, CAs can be created:
- Bar rows
- Components
- Custom bars
- Experiments
- Recipes
- Materials
- Phases
- Orders
- Resources
- Resource pools
- Operations*
- Procedures*
- Units
- Unit pools
* See excursus below.
A new CA is created via the menu Project > Custom Attributes. First, select the category, and via right-click > New, open a dialog asking whether a dynamic or permanent CA should be created. In the window that opens, assign a name to your CA, optionally specify a unit and the data type. As data types you can select Number, Color, Selection (a list of values), Text, Boolean truth value, or Date. For permanent CAs, you can choose whether they should be read-only and whether they should be reset at the start of the simulation.

Permanent vs. dynamic vs. “fully dynamic” Custom Attributes
The biggest difference between permanent and dynamic CAs is the availability of the property(s) before and after the simulation. While permanent CAs can be edited in the object dialogs before the simulation and displayed there or in the Gantt chart after the simulation, the dynamic CAs are only available during the simulation in VBA. The following images showcase how CAs can be displayed in dialogs and in the Gantt chart.



All CAs that are created via the menu, both permanent and dynamic CAs, receive a specific data type: numbers are stored as Double, text as String, etc. Figure 5 shows the values with which the CA types are initialized.

Saving objects in Custom Attributes
In addition to the data types already presented, even objects can be stored in CAs. In that case, the CAs are created only during the simulation and receive, for example, a unit object. Let us call these CAs “fully dynamic”.
Since the CustomAttributes property in VBA is a dictionary object after all, new CAs can be created flexibly and dynamically (i.e., during simulation). CAs added in this way are not limited to the usual data types, but can also include objects such as Table, Dictionary, Unit (e.g., the main unit as CA of an order). Such a type of CA is called “fully dynamic” here.
If an unknown CA is queried, be it because of a typo (“Mterial”) or because the CA has not yet been set (e.g., unit of the order is not yet known), the data type is Empty (see Tip and Trick “Much Adoe About Nothing, Null, Empty”). Figure 5 shows that the dynamic CA material previously created via the user dialog contains an empty string, since it has already been defined as text. The query of the “fully dynamic” CA Size returns Empty and can contain any data type: strings, numbers, and object references. In INOSIM 13 and older versions, CAs are initialized with Null (see Tip and Trick “Much Adoe About Nothing, Null, Empty”).

Particular care should therefore be taken to ensure that the names of CAs created via the user interface is also spelled correctly in VBA. Otherwise, a new “fully dynamic” CA is accessed. Please note in particular that the names of CAs are case–sensitive, unlike the names of units or recipes, for example.
Examples for the use of fully dynamic CAs
- Attach the Cond object of a link condition to a dynamic CA of the associated order.
- Assign a dictionary object with recipe parameters to the CA of a recipe.
- Assign a table object to each unit in which all processed orders as well as the waiting times in that order are documented.
Example LinkCondition-Object
In the example model (see Downloads), the beginning of the cleaning should be delayed as long as another unit is still allocated, so the cleaning will be started only after the end of that allocation. Normally, this can be represented by synchronization shortcuts or Signal and Wait operations. If the rules are more complex, it is useful to implement a link condition in the recipe and use the Suspend method to stop the procedure. The procedure can be resumed then by calling the Resume method on a time-based or event-triggered basis. Therefore, the LinkCondition object that was suspended before must be accessible. This could be stored in a global variable, a global dictionary, or even a “full-dynamic” custom attribute, e.g., of order.
Sub cond_reaction(cond As OrderLinkCondition)
If Units("Mixer").ActiveOperations.Count > 0 Then
cond.Suspend
cond.OrderOperationFrom.Order.CustomAttributes("Cond") = cond
'CA "Cond" was not created via the user interface
End If
End Sub
At an appropriate time, such as the End event of the last operation of the last batch, it is checked whether a waiting LinkCondition object is in an order CA. For this the Resume method is invoked and then the CA is set to Nothing.
Sub mixing_end(cop As OrderOperation)
'only after the last batch of the order has finished and only if there is an object in the CA "Cond"
If cop.OrderProcedure.Batch = cop.Order.Batches AndAlso IsReference(cop.Order.CustomAttributes("Cond")) Then
Dim cond As OrderLinkCondition
cond = cop.Order.CustomAttributes("Cond")
cond.Resume
cop.Order.CustomAttributes("Cond") = Nothing
'reset the CA value to Nothing, since a resumed Condition has no further use
End If
End Sub
Excursus: Why always two categories for operations and procedures?
Moreover, in case of CAs for operations and procedures, there is a specialty, as there are two categories:
- for operations
- „Unit operations (Master recipes and Recipe modules)“
- „Unit operations“
- for Procedures
- „Unit procedures (Master recipes and Recipe modules)“
- „Unit procedures“
When an order executes a recipe during the simulation, the unit procedures become unit procedures and the unit operations become control operations. While the former (“…master…”) are unique in the model, copies are created in the form of “…control…” for each execution of recipe components. Their properties, such as Duration and Amount [duration/amount], can be changed via VBA.
Permanent CAs of unit operations and unit procedures can be viewed and edited in the Recipe Editor. Permanent CAs of control operations and unit procedures, i.e. components of the actually executed orders, can be displayed in the Gantt chart.
More Questions?
Want to know more about this topic or have another question? Please contact us!
More Tips & Tricks
Custom Probability Distributions
Learn how to use the implemented probability distributions in INOSIM to add stochastic failures or process parameters to your model, and how to set up…
When modeling a production process, it may happen that a certain property is not built into the software: the material of the equipment, or the…
Collaboration and Version Control for INOSIM Models
Often enough, INOSIM models are maintained by several people. One challenge is to provide everyone involved with the most up-to-date version and to keep them…