Image "avalski-toranj-2-1-640x1138.jpg" by urbancitystudio.org is licensed under CC BY-SA 4.0. This work has been cropped and filtered from the original.
Image "Belgrade_Waterfront_2_(cropped).jpg" by Kallerna is licensed under CC BY-SA 4.0. This work has been cropped and filtered from the original.

Data Model

1. Data Foundations (The Convention of Origin)

1.1. Legal types

The Aero-Factory architecture classifies data into two distinct legal states, Raw and Refined, governed by the Convention of Origin.

Raw Data is the high-fidelity, original stream captured at the point of ingestion (Vortex Site Hub or Vortex Edge). It contains the "Technical Truth" in its most granular form, including precise millisecond timestamps, unmasked personal identifiers (PII) such as operator names, and raw sensor values. Because it reflects the unfiltered state of the factory floor, Raw Data is essential for deep forensics, real-time machine control, and local troubleshooting, but it is restricted to the local site to comply with data privacy regulations and bandwidth constraints.

Refined Data represents the sanitized and business-ready version of that information, produced after passing through the Refinement Gate at the L5 Central Hub. In this state, the data has been scrubbed of sensitive identifiers (e.g., specific names are replaced with anonymized IDs), and high-frequency telemetry is often aggregated or normalized for corporate-level reporting. Refined Data is the only legal type permitted for broad consumption across the corporate enterprise and cloud layers, as it ensures compliance with global data governance policies while providing the structured, high-level context required for business intelligence and long-term analytics.

1.2. Payload types

The Aero-Factory architecture classifies data into two distinct payload states, B2MML and CDM (Conceptual Data Model), governed by the Convention of Origin.

1.2.1. B2MML

The B2MML Payload represents the operational "Core" of the UDS structure, providing a standardized technical snapshot of the asset or process based on the ISA-95 framework. It focuses on the high-fidelity, real-time telemetry required for shop-floor orchestration, such as equipment states, physical measurements, and process variables. By utilizing the B2MML (Business To Manufacturing Markup Language) standard, the architecture ensures that technical data remains vendor-agnostic, allowing different systems to interpret sensor values and machine statuses without requiring custom translation layers for every new piece of hardware.

Within the UDS envelope, this payload carries the "Technical Truth" of the factory floor, typically including specific parameters like fluid temperatures, flow rates, and nozzle statuses. While it is highly detailed at the L4 Site Hub, the B2MML payload is the primary target of the Refinement Gate, where technical values are normalized or aggregated before being passed to higher-level corporate systems. This separation ensures that the granular technical complexities of the manufacturing process are contained within a structured format that is both human-readable and machine-interoperable across the entire Aero-Factory ecosystem.

1.2.2. CDM

The Vortex CDM Payload serves as the business "Extension" of the UDS structure, bridging the gap between the physical factory floor and the corporate enterprise layer. Unlike the raw technical data found in the B2MML core, the Common Data Model (CDM) focuses on the financial, legal, and strategic context of the information. It maps technical assets to their corresponding business entities, providing essential metadata such as ownership details, cost center allocations, and contract-specific billing categories. This layer transforms a simple machine status into a meaningful business event that can be immediately processed by ERP, HR, or procurement systems.

By maintaining this dedicated payload, the Aero-Factory architecture allows for advanced corporate-level orchestration, such as tracking ESG metrics like carbon footprint indices or calculating real-time labor costs associated with specific maintenance tasks. The CDM payload remains highly modular; while the technical B2MML data may change frequently based on the hardware vendor, the CDM structure provides a consistent, brand-level interface for corporate analytics. This ensures that even as factory floor equipment evolves, the business logic used for reporting and decision-making remains stable and standardized across the entire global organization.

1.3. The Convention of Origin

The Aero-Factory RA eliminates the need for complex topic tagging by relying on the Convention of Origin. Data integrity and legal status are determined by the broker layer providing the stream:

  • L4- (Vortex Site Hub, Vortex Edge): Implicitly Raw Data. High-fidelity telemetry containing private identifiers (PII) and unmasked operational metadata.
  • L5+ (Vortex Central Hub, Vortex Cloud Hub): Implicitly Refined Data. Sanitized and business-ready streams where PII is masked and values are normalized.

Examples of comparative data states:

Raw Data Refined Data
Operator Identity Full Name: "Petar Petrović" Anonymized ID: "OP_742"
Measurement Precision Flow: 42.5834 L/min (Real-time burst) Flow: 42.6 L/min (Normalized average)
Asset Detail Internal Serial: "SN-99432-XYZ" Fleet ID: "Truck_01"

The distinction between raw and refined data is critical both operationally and legally. From a technical perspective, raw data is essential for forensic auditing and training AI models, as it preserves the high-fidelity signals required for root-cause analysis; however, its volume can overwhelm L5/L6 systems, making refined (contextualized) data the preferred choice for real-time KPIs and executive dashboards. From a legal and compliance standpoint, raw data often carries significant liability, as it may contain sensitive operational signatures or unmasked identifiers that fall under strict data residency and privacy regulations. Conversely, refined data provides a layer of abstraction that simplifies regulatory reporting and intellectual property protection by ensuring that only "summarized outcomes", and not proprietary raw process secrets, are transmitted across global cloud boundaries.


Vendor applications are strictly required to consume data only from the Vortex Hub layer that corresponds to their assigned integration level. An application operating at the L4, for example, must rely solely on the Vortex Site Hub to access Raw data, while global applications at the L5 level are directed to the Central Hub for Refined data.


Any attempt at "cross-layer" subscription, such as an L4 application attempting to pull data directly from the Central Hub, is strongly discouraged. This policy is enforced to maintain network efficiency and logical data separation. Deviations from this standard are permitted only with explicit management approval and a formal acceptance of the risks regarding network congestion and architectural misalignment.

2. Unified Data Structure

The Unified Data Structure (UDS) serves as the universal standard for data exchange within the Aero-Factory ecosystem, designed to ensure semantic integrity and contextual connectivity across all architectural layers. This standard acts as the singular carrier for diverse information streams, or "Data Highways", ranging from standard telemetry (Digital Thread Highway), to complex media and video streams (Vision & Analytics Highway), and critical commands (Command & Control Highway) that govern physical processes. By implementing UDS, the architecture eliminates data silos; regardless of its nature or origin, every information flow adheres to a strictly defined structure that guarantees recognizability and immediate utility at any point in the network.

Technically, the standard is realized through the UDS Envelope, a JSON-formatted object that encapsulates both the payload and its essential metadata. This envelope is designed to be entirely agnostic to the transport layer, enabling seamless distribution via the standard protocols defined in the Data Architecture, such as MQTT for real-time messaging, AMQP for robust routing, or gRPC for high-performance communication. This approach ensures that once data is packaged within a UDS Envelope, it can transit securely and unchanged across disparate systems—from Edge devices at L2 to advanced AI tools at L6—while maintaining its "legal" status and full business context.

UDS Anatomy (the Envelope):



  • UNS: The immutable "return address" and semantic anchor. It ensures the payload is discoverable within the enterprise hierarchy and provides the context required to generate the deterministic UUID v5.
  • Header: UNS Path, Deterministic UUID v5, and Origin Timestamp.
  • B2MML Payload: Operational "Core" (ISA-95 compliant technical state).
  • Vortex CDM Payload: Business "Extension" (Ownership, ERP mapping, ESG metrics).

2.1. UNS Topic Hierarchy & Nomenclature

2.1.1. The Unified Namespace (UNS) Standard

The Aero-Factory RA enforces a strict Unified Namespace (UNS) hierarchy based on the ISA-95 functional model. This ensures that every data point has a unique, discoverable address that reflects the physical and logical structure of the enterprise.

Standard Structure:

Enterprise / Site / Area / Line / Asset / [Functional_Group]
2.1.2. Nomenclature Rules

To maintain Topic Purity and system scalability, the following rules are mandatory:

  • Nouns over Verbs: Topics describe the source and attribute (e.g., .../Truck01/Position), not the action (e.g., .../Truck01/Moving).
  • Standardized Casing: All path elements must use PascalCase to ensure consistency across different vendor integrations.
  • Logical Grouping: Use the optional Functional_Group (e.g., Raw/Refined (for Telemetry), Status, Stream, Cmd) to separate data types at the asset level.
2.1.3. Practical Application

Example of a telemetry topic for a De-Icing vehicle operating at Belgrade Airport:

UNS Level Example Value Description
Enterprise Aero Global corporate entity.
Site BG Belgrade Airport facility.
Area Ground Ground Support Equipment zone.
Line DeIce The de-icing service department.
Asset Truck01 The specific vehicle identifier.
Group Raw Branch hosting the UDS structured raw telemetry.

2.2. Header

The Header serves as the metadata wrapper. It identifies the origin and ensures uniqueness across the entire global namespace.

{
  "uds_header": {
    "uns_path": "Aero/BG/Ground/DeIce/Truck01/Raw",
    "uuid_v5": "550e8400-e29b-41d4-a716-446655440000",
    "origin_timestamp": "2026-02-21T14:50:00.123Z",
    "payloads_hash": "5e9d9b...", /* HMAC-SHA256 */
    "schema_ref": "v1.2/equipment_property.json",
    "version": "1.0"
  },
  "b2mml_payload": { ... }, 
  "vortex_cdm_payload": { ... }
}

2.3. B2MML Payload

The operational "Core". It uses the EquipmentProperty entity from the B2MML standard to provide a strictly typed readout of a single sensor tag.

"b2mml_payload": {
  "EquipmentProperty": {
    "ID": "Fl_Temp_Sensor_01",
    "Description": "Main nozzle fluid heating temperature",
    "Value": {
      "ValueString": "85.4",
      "DataType": "float",
      "UnitOfMeasure": "°C"
    },
    "Status": "Good",
    "QualityCode": "0x00",
    "LastUpdated": "2026-02-21T14:50:00.120Z"
  }
}

2.4. Vortex CDM Payload

The business "Extension". This domain object (CDM) ensures that the technical telemetry is contextually linked to active business processes (Work Orders and Materials).

"vortex_cdm_payload": {
  "WorkOrder": {
    "WorkOrderID": "WO-2026-AER-9921",
    "JobType": "De-Icing_Standard",
    "Status": "In_Progress"
  },
  "Material": {
    "MaterialID": "Type_IV_Fluid",
    "BatchNumber": "B-2026-X4",
    "MaterialDefinitionID": "Anti-Ice_Fluid"
  },
  "Accounting": {
    "CostCenter": "BG_OPS_04",
    "OwnerEntity": "GroundLogic"
  }
}

Note on Payload Arrays: Both b2mml_payload and vortex_cdm_payload are designed to handle single objects by default. If a message contains multiple entities, they must be formatted as an array within the respective JSON fields (e.g., "b2mml_payload": [{...}, {...}]).

3. Core Data Objects Classification

Data objects are categorized into three primary models to ensure a clean separation of static master data and transactional telemetry.

B2MML Content (Operational) Vortex CDM Content (Business)
Resource Model Equipment status, technical specs (RPM, PSI), maintenance hours. Asset ownership (Entity ID), lease terms, cost center mapping.
Material Model Fluid types (Type I/II), chemical properties, current quantity. Unit price (ERP), vendor SLA, carbon footprint (ESG) index.
Personnel Model Operator certification level, active shift, safety training status. Payroll ID, labor cost rates, HR compliance flags.

This classification serves as a structural guide for mapping factory data to business value. It is important to note that this list is exemplary and not exhaustive for the purpose of this RA document. Full schema definitions for each model are to be finalized within the specific Solution Architecture (SA) phase.

4. The Refinement Gate (Data Transformation)

As data moves from L4 to L5, it passes through the Refinement Gate. This process transforms Raw UDS into Refined UDS by applying three primary filters:

  1. Scrubbing: Removal or hashing of sensitive personal data (PII).
  2. Aggregation: Normalization of high-frequency bursts for cloud efficiency.
  3. Enrichment: Cross-referencing B2MML fields with ERP Master Data via Vortex CDM.
UDS at L4 (Raw) UDS at L5 (Refined)
Header UNS: .../Truck01, TS: Precise ms (local time zone) UNS: .../Truck01, TS: Normalized sec if applicable (Zulu time zone), Refinement Stamp
B2MML Operator: "Marko Markovic", Serial: "SN-987" Operator: "ANON_ID_9", Serial: "REDACTED"
Vortex CDM Local Vendor ID, Raw Lease Info Corporate Partner ID, ERP Cost Center

The Refinement Gate is a standard component of Vortex Central Hub. You can see more details within Vortex Data Broker chapter of Appication Architecture section.

5. Data Footprint & Optimization Strategies

Although the UDS envelope significantly increases the byte count per individual tag readout compared to raw protocols, this "heavy footprint" is a deliberate architectural choice. It enables semantic interoperability and drastically reduces the computational overhead at the L6 layer.

  • Contextual Autonomy: Every packet is self-describing. Even if central databases (ERP/MES) are offline, the data remains actionable because it carries its own business context (Work Order, Material ID).
  • Zero-Processing at L6: AI tools and analytical engines do not waste resources performing expensive "joins" between telemetry and business data. Data arrives "analytics-ready," linearly reducing the required cloud or data-center CPU power.
  • Compliance & Audit: Modern industrial standards, such as the Asset Administration Shell (AAS) and ISA-95, mandate an enriched data structure to ensure that telemetry is not just a raw value, but a semantically transparent 'Digital Twin' payload that carries its own identity, unit, and business context.

Transfer Optimization Techniques

To neutralize the impact of the verbose JSON format on network throughput, the Vortex architecture implements three layers of optimization:

  1. Vortex Edge Aggregation: Instead of sending a packet for every micro-change at the L1 level, the Vortex Edge performs aggregation. Multiple readouts from the same asset or sensor group are bundled into a single transfer cycle, reducing network header overhead.
  2. Deadband Filtering: This is the primary noise reduction technique. Data is transmitted to the Management/Digital Thread Highway only if the value deviates from the previous one by a defined threshold (e.g., ±0.5%). If the value remains stable, no UDS envelope is sent, drastically conserving bandwidth.
  3. Binary Encoding (gRPC/Protobuf): Before transmission over a TLS-encrypted channel, the JSON envelope can be mapped into a binary format (Protocol Buffers). This reduces the packet size by up to 80% while preserving the full structure of the B2MML and CDM objects.
Note: While Encryption (TLS) adds a small fixed overhead, the use of TLS 1.3 with session resumption techniques minimizes handshake latency, making the transfer of "rich" UDS packets secure and efficient even on unstable industrial networks.

Digital Highway Optimization Techniques

An optional Lightweight Digital Thread (LDT) Highway can be introduced as a high-priority, redundant data plane designed to ensure operational continuity in environments where network infrastructure or compute power is constrained.

By stripping the payload down to its absolute essentials (the immutable UDS Header and the core B2MML Technical Truth) this highway allows for a bypass of the heavy processing typically required by the full Refinement Gate. This "skinny" profile drastically reduces the byte count and serialization overhead, making it an ideal solution for legacy "Brownfield" sites or high-frequency telemetry where sub-second latency is non-negotiable for local time-series databases and real-time dashboards.

Despite its minimal footprint, this optional highway remains a first-class citizen of the Aero-Factory ecosystem by adhering strictly to the Unified Data Structure. Because it preserves the deterministic UUID v5 and the standardized UNS path, it eliminates the risk of data siloing; the enterprise layer can seamlessly re-synchronize these lightweight bursts with the enriched B2MML and CDM payloads arriving on the standard highways. The LDT can be introduced as a pragmatic "fail-safe" that decouples semantic depth from transmission cost, allowing the global organization to maintain a single source of truth while providing the agility required for the plant floor’s immediate tactical needs.

Next: Architectural Principles