Anatomy of a DNA — Technical Structure

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

SubclassDescriptionExample objects
PlacedObjectTypePhysical objects placed along alignments. Full feature set: alignment, 2D/3D geometry, connections, properties.Signals, switches, axle counters, masts, cabinets
AlignmentObjectTypeLinear alignment objects representing tracks, roads, wires.Track alignment, contact wire, earthing conductor
AreaObjectTypeRegion objects defined by closed polylines.Temporary Shunting Area, Viewport, Station area
TableObjectTypeTabular data objects with no geometry.Signal table, interlocking table, earthing table
XRefObjectTypeRead-only cross-references to objects in other DWG files.XRef’d signals from another discipline’s model
CloneObjectTypeClone/copy references to other objects.Copied reference objects

Sub-entities per object type

Each object type can have up to six optional sub-entities:

  1. Properties — Custom property definitions with override capabilities. Properties have default values, allowed value lists, data types, and can include Lua formulas.
  2. Geometry 2D — 2D symbol definitions specifying which DWG symbol to display, with position offsets, rotations, and layer/color/linetype overrides.
  3. Geometry 3D — 3D component references for export and visualization. Supports parametric assembly from partial 3D geometries for objects with many variations.
  4. Jig (Snap Points) — Dock points and display points that define how the object snaps to alignments and other objects during insertion.
  5. Model Checks — Links to Lua-based validation rules that run automatically when the object is placed or updated.
  6. 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:

ScopeMeaningExample
GlobalAvailable to all object types in the project“Earthing method”
DisciplineAvailable to all object types in a specific discipline“Signal mounting height”
ObjectTypeAvailable 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?

Would you like to receive our newsletter?