This page provides a detailed technical breakdown of what a DNA file contains, for technical visitors, potential agents, and advanced users who want to understand the data model.
High-level structure
A DNA is organized hierarchically. At the top level, a DNA project contains:
DNA Project
├── Disciplines (organizational units — e.g., Signalling, Overhead Lines)
│ ├── Object Types (the core building blocks)
│ ├── Layers (CAD layers for drawing organization)
│ └── Lua Functions (automation scripts)
├── Colors (RGB definitions referenced throughout)
├── Text Styles (typography for annotations)
├── Linetypes (dash/dot patterns)
├── Property Definitions (custom attributes)
├── Show Layers (visualization hierarchy)
├── Relation Definitions (typed connections between objects)
│ └── Relations (individual connection rules)
├── Relation Spaces (groupings for relation participation)
└── Annotations (24 subtypes for CAD representation)
Object types — the core of a DNA
Object types are the fundamental building blocks. Every railway object that a user can place in a BIM model is defined by an object type declaration in the DNA.
Six subclasses
| Subclass | Description | Example objects |
|---|---|---|
| PlacedObjectType | Physical objects placed along alignments. Full feature set: alignment, 2D/3D geometry, connections, properties. | Signals, switches, axle counters, masts, cabinets |
| AlignmentObjectType | Linear alignment objects representing tracks, roads, wires. | Track alignment, contact wire, earthing conductor |
| AreaObjectType | Region objects defined by closed polylines. | Temporary Shunting Area, Viewport, Station area |
| TableObjectType | Tabular data objects with no geometry. | Signal table, interlocking table, earthing table |
| XRefObjectType | Read-only cross-references to objects in other DWG files. | XRef’d signals from another discipline’s model |
| CloneObjectType | Clone/copy references to other objects. | Copied reference objects |
Sub-entities per object type
Each object type can have up to six optional sub-entities:
- Properties — Custom property definitions with override capabilities. Properties have default values, allowed value lists, data types, and can include Lua formulas.
- Geometry 2D — 2D symbol definitions specifying which DWG symbol to display, with position offsets, rotations, and layer/color/linetype overrides.
- Geometry 3D — 3D component references for export and visualization. Supports parametric assembly from partial 3D geometries for objects with many variations.
- Jig (Snap Points) — Dock points and display points that define how the object snaps to alignments and other objects during insertion.
- Model Checks — Links to Lua-based validation rules that run automatically when the object is placed or updated.
- Presets — Configuration templates (insertion variants) that pre-fill properties and settings for common placement scenarios.
Built-in properties
Every object type inherits 18 common properties that are always present, covering identity (id, RcType, code, name), classification (Discipline, Stage, Variant), presentation (Color, Layer, Linetype, Lineweight), scripting (LuaExpressions, Var0–Var9), and metadata (lang, description). Subclasses add additional intrinsic properties; PlacedObjectType, the most feature-rich, has 31 intrinsic properties in total.
Properties system
A DNA supports a flexible, scoped property system:
| Scope | Meaning | Example |
|---|---|---|
| Global | Available to all object types in the project | “Earthing method” |
| Discipline | Available to all object types in a specific discipline | “Signal mounting height” |
| ObjectType | Available only to a specific object type | “Number of aspects” (for signals only) |
Property definitions include a name and description, data type (string, integer, float, boolean, enumeration), default value, allowed values (enum list or range), validation flags, and an optional Lua formula — a small program that computes the property’s value from the database.
At the object type level, a property definition can be overridden to customise default values, insert options, and visual display attributes specific to that object type.
Relations system
Relations define typed, constrained connections between objects.
A Relation Space is a named category that groups object types for relation participation. Each object type declares at most one Relation Space, and a special wildcard space “Anything” matches all object types.
A Relation Definition groups related relations and declares source spaces. Each individual Relation has a forward direction (e.g., “Is distant signal for”), an optional reverse direction (e.g., “Is signal announced by”), cardinality constraints, CAD styling, and Lua integration names for scripting access.
Relations power several critical workflows: database traversal via Lua, automatic numbering (e.g., balises inside an ETCS group), table generation (interlocking and signal tables), and earthing plans.
Layers, colors, linetypes
A DNA declares the complete visual language for CAD production. Colors are RGB triplets with semantic naming, referenced throughout the DNA. Layers are organized by discipline, with names encoding construction stages for the Stage Manager. Linetypes define dash/dot patterns, and Text Styles define typography for annotations.
Annotations
A DNA supports 24 annotation subtypes for CAD representation, organized in two tiers: base annotations (with color, magnification, and layer settings), annotations with text (10 subtypes), and direct subtypes (14 subtypes for non-text annotations such as symbols and graphics).
Export format
A DNA is serialized as XML for consumption by the RailCOMPLETE AutoCAD plugin. The export pipeline serializes object types with all sub-entities, resolves internal references, preserves CAD styling, and generates XML compatible with the RailCOMPLETE runtime. The compiled DNA, along with 2D/3D symbol libraries and Lua scripts, is delivered to end users inside their DWG project files.
← Back to What is DNA?

