Controller Objects

The Controller is made up of a variety of objects (see OP_OBJECT_TYPE). Each object contains any number of attributes (see OP_ATTRIBUTE). An object also can be the owner of other objects. For example, RT-LAB owns a Project and the Project owns Models.

These objects are organized in a tree as shown in Figure 3. Each object has a unique Reference ID and contains attributes that may be be accessed via Generic API calls (see OP_COMMAND).

There are certain restrictions to the placement of objects in the Controller object tree. An important definition is that there is always exactly one (1) project per Controller. There may exist several Controllers concurrently, but every Controller will hold one project.

RT-LAB Global Object

This object is the root of the Controller’s object tree. All other objects are directly or indirectly children of RT-LAB. The attributes that RT-LAB contains are the default settings used when children are created.

For example, if ATT_TARGET_PLATFORM of RT-LAB is set to REDHAWK_TARGET and a new Model is created, its default value will be REDHAWK_TARGET until modified.

Project Object

The project object mainly serves as a container for models. A project may contain anywhere between 0 and 253 models. It contains attributes.

Model Objects

Models contain a set of subsystems that are controlled as a whole to execute simulations. Models are defined by block diagrams developed with one of the following 3rd party applications: Matlab SimulinkTM, EMTP WorksTM.

Subsystem Objects

Subsystems contain various model sub-elements such as signals, block parameters, variables, etc. The block diagrams that make up a Model are divided into Subsystems to both structures the model and optimize block interactions by localizing certain operations to specific hardware (see the “Building Models” section of the User Guide).

Controller Lists

Any controller object that has children necessarily contains lists. Figure 3 is only a simplified representation of the relationships between objects contained in the controller. When examined in more detail, each object contains a list for each type of children it owns. Figure 4 shows that Project does not directly own any Models but instead owns a Model List that in turn owns all the Models.

The same relationship is true for all Controller objects and lists. Objects can only own lists, and lists can only own objects. This organization helps classify an objects children by type. It also gives the user the liberty of adding or removing children from the parent object or from the intermediate list.

As shown in Figure 5 all objects own exactly one (1) instance of each list type. Lists, however, may own any number (see OP_OBJECT_TYPE for exact upper bound) of objects, so long as they are all of the corresponding list types. For example, a Model List owns only Model objects, and a Model owns an Environment List, a Subsystem List, and a Transfer File List.

Reference IDs

All object and list instances are addressable via their unique reference ID. Reference IDs are 64-bit integers that are globally unique. Reference IDs allow users to perform Generic commands on objects as well as attributes read or write operations.

There are several reference IDs that are static. RT-LAB will always have the same reference ID, OP_RTLAB_OBJ.

All direct children of RT-LAB will also maintain the same reference IDs, e.g. ProjectList, etc. Since each Controller only contains one project, it can be accessed unconditionally using OP_SINGLE_PROJECT.