# Galaxy Repository Object Layout

## Object Hierarchy

Galaxy objects are organized in a tree hierarchy. The root is the Galaxy itself (ZB), with objects nested under areas and other containers:

```
ZB (Galaxy)
├── UnassignedArea
├── DEV
│   ├── DevAppEngine
│   ├── DevPlatform
│   └── TestArea [TestArea]
│       └── DevTestObject
│           ├── TestChildObject [TestChildObject]
│           ├── TestMachine_001
│           ├── DelmiaReceiver_001 [DelmiaReceiver]
│           └── MESReceiver_001 [MESReceiver]
```

Objects have a **tag_name** (instance name, e.g. `TestMachine_001`) and optionally a **contained_name** shown in brackets (the template/type, e.g. `[DelmiaReceiver]`). Parent-child containment defines the deployment and organizational structure.

## Contained Name vs Tag Name

Each child object has a **contained_name** (its local name within its parent) and a globally unique **tag_name**. When browsing the hierarchy, we want to see the contained name path; when referencing tags at runtime, the tag_name is used.

| Hierarchy Path (contained names) | Tag Reference (tag_name) |
|----------------------------------|--------------------------|
| `TestMachine_001.DelmiaReceiver.DownloadPath` | `DelmiaReceiver_001.DownloadPath` |
| `TestMachine_001.MESReceiver.MoveInBatchID` | `MESReceiver_001.MoveInBatchID` |

The contained_name (`DelmiaReceiver`) is the human-readable name scoped to its parent, while the tag_name (`DelmiaReceiver_001`) is the system-assigned globally unique name. Translation between the two is needed when going from a hierarchy browse to tag-level data access.

## Target OPC UA Server Structure

The OPC UA server should mirror the Galaxy hierarchy using contained names for folder/container structure. Attributes appear as tags within their object's container, and child objects appear as sub-containers. When an OPC UA client reads/writes a tag value, the contained name path is translated to the tag_name reference.

```
ZB/
└── DEV/
    └── TestArea/
        └── TestMachine_001/
            ├── MachineID              → reads/writes TestMachine_001.MachineID
            ├── MachineCode            → reads/writes TestMachine_001.MachineCode
            ├── DelmiaReceiver/
            │   ├── DownloadPath       → reads/writes DelmiaReceiver_001.DownloadPath
            │   ├── JobStepNumber      → reads/writes DelmiaReceiver_001.JobStepNumber
            │   ├── PartNumber         → reads/writes DelmiaReceiver_001.PartNumber
            │   └── RecipeDownloadFlag → reads/writes DelmiaReceiver_001.RecipeDownloadFlag
            └── MESReceiver/
                ├── MoveInBatchID      → reads/writes MESReceiver_001.MoveInBatchID
                ├── MoveInCompleteFlag → reads/writes MESReceiver_001.MoveInCompleteFlag
                ├── MoveInFlag         → reads/writes MESReceiver_001.MoveInFlag
                └── ...
```

Folders (ZB, DEV, TestArea) are structural — they organize the browse tree but don't have tags. Containers (TestMachine_001, DelmiaReceiver, MESReceiver) hold both attributes (tags) and potentially child containers.

## Tag (Attribute) View

Tags represent the data attributes exposed by objects. They are referenced in a flattened dot-notation format using the tag_name:

```
<tag_name>.<AttributeName>
```

Examples:
- `TestMachine_001.MachineID`
- `TestMachine_001.MachineCode`
- `MESReceiver_001.MoveInBatchID`
- `MESReceiver_001.MoveInCompleteFlag`
- `MESReceiver_001.MoveInJobSequenceNumber`
- `DelmiaReceiver_001.DownloadPath`
- `DelmiaReceiver_001.JobStepNumber`
- `DelmiaReceiver_001.PartNumber`
- `DelmiaReceiver_001.RecipeDownloadFlag`

This flat view collapses the hierarchy — all attributes across all objects appear as `tag_name.AttributeName` regardless of where the object sits in the containment tree.