Skip to content
NATO Edge 26 - 17–19 November 2026 - Izmir - Stand G19 Book a meeting at our stand
AOC Türkiye: Dominating the Spectrum - 26–27 November 2026 - Ankara Book a meeting at the event
Data network with flickering blue lights

02 Connect Real-Time Data Distribution Layer

Mil-DDS

It connects critical systems not to one another, but to a common data backbone. As the system grows, it is not the number of connections that increases, but the amount of shared data.

Mil-DDS is a real-time data distribution layer developed by MilSOFT that enables sensors, control software and operator displays in critical systems to share data over a common data backbone, rather than being connected to one another individually.

  • The Only Turkish Manufacturer Listed in the OMG DDS Vendor Directory as of September 2026
  • Under continuous development since 2004
  • CMMI Level 5

How It Works

From discovery to growth: four steps

Illustrative flow - 01 / 04

PublishersSubscribersDDS logical data spaceData-centric communicationRadar AlphaRadar AAirTrackRadar BravoRadar BAirTrackRadar CharlieRadar CAirTrackEO/IR processorEO/IREOObservationNavigation unitNavigationPlatformPositionMission displayDisplayFusedTrack + NavMission recorderRecorderMulti-topic archiveTactical plannerPlannerFusedTrackNew mission consoleConsoleFusedTrackFusion applicationFusionFusedTrackApplication-level processingAirTrackEOObservationPlatformPositionFusedTrackAutomatic discoveryTopic, data type and QoS matchingNo central brokerNew participant joins mid-stream
  1. Applications automatically discover publishers and subscribers within the same DDS environment.

  2. Publishers and subscribers are matched based on the required data and compatible communication conditions (topic, data type, QoS).

  3. Published data is distributed to matching subscribers according to defined QoS policies.

  4. New publishers and subscribers join the system without interrupting the existing data flow.

This arrangement is no coincidence; it is the architecture itself

Problem

The problem is not that the systems cannot be connected; it is that as the system grows, the systems become interdependent

In critical systems, dozens of components — sensors, control software, operator displays, third-party subsystems — are integrated with one another through dedicated connections and interfaces. As the system grows, so does the number of connections, interfaces and data flows that need to be managed; the integration, testing and maintenance workload grows in parallel.

Adding a new component to the system may require new interfaces, adapters or data conversions to be developed for the existing components. Each new connection creates a new dependency that has to be tested, maintained and protected from the impact of changes.

This scenario is not new; what is new is that systems are growing much faster than before, driven by the number of sensors, autonomy and artificial intelligence capabilities. The integration burden that seems manageable today can turn into a significant scalability problem with the next capability upgrade.

The results manifest themselves in different ways at every level of the organisation
  • Developer / Integrator

    As new components are added to the system, the number of integrations that must be set up and maintained with existing applications increases.

  • Systems architect

    Mapping, managing and keeping the direct dependencies between components up to date becomes increasingly difficult.

  • Operations / Maintenance team

    A change to a component or interface can affect the other components that depend on it directly and makes fault isolation more difficult.

  • Organisation

    Because systems from different projects and suppliers work with different interfaces and communication structures, the cost of reuse and interoperability rises.

It’s not difficult to connect things. The difficult part is keeping connection complexity from growing as the system grows.

Solution

As the system grows, data sharing scales, not connection complexity

The solution is to bring components together in a common data distribution layer instead of linking them to one another through dedicated connections. In a publish-subscribe architecture, a component publishes data and the components that need it subscribe to that data; this removes the need for a separate application-to-application connection for each new participant.

Decision-making superiority begins not on the ground, but at the data layer

Product

What is Mil-DDS?

Mil-DDS is a real-time data distribution infrastructure developed by MilSOFT for distributed and mission-critical systems.

It is not merely a single runtime component. It offers an integrated product structure made up of Mil-DDS Core and development, monitoring and validation tools, supporting development, integration and operation within the same ecosystem. As a result, developers, system architects and operations teams work on the same distributed data infrastructure.

Mil-DDS is based on the OMG DDS standard and the DDSI-RTPS protocol. This standards-based approach has formed the foundation of the product architecture from the outset. It has long been used in critical systems in the Turkish defence industry.

Mil-DDS is a real-time data infrastructure that ensures data in distributed systems is delivered at the right time, to the right components and in line with defined communication policies

Capabilities

  • Data-Centric Architecture

    Rather than being connected directly to one another, applications publish or subscribe to the data they need. New publishers and subscribers can join the system through automatic discovery; data distribution does not require a central message server.

    Goal: As the system grows, let data sharing scale rather than direct integration dependencies.

  • Manageable Data Flow with QoS

    Under the Reliability, Deadline, Durability, Ownership and Liveliness policies, each data stream is defined according to its own reliability and timing requirements.

    Goal: Each data flow is managed according to its own reliability, timing and resource requirements.

  • Standards-Based Interoperability

    Compliance with the OMG DDS / DCPS specification and the DDSI-RTPS wire protocol; standards-based interoperability in heterogeneous DDS environments; extensible data types via DDS-XTypes.

    Goal: To safeguard the existing investment, to establish a hybrid architecture, and to avoid being tied to a single supplier.

  • Proven Platform Support

    Windows, Linux, Embedded Linux, Solaris, QNX and VxWorks operating systems; x86/x86-64, ARM, PowerPC and SPARC processor architectures; C++, Java and C# APIs.

    Goal: To present platform independence not as a claim, but as a verified list.

  • Development and Validation Ecosystem

    Tools for data modelling, live traffic monitoring, and recording and replaying data flows are part of the product; they speed up integration and testing.

    Goal: To offer not just a runtime, but an ecosystem that encompasses the development and validation processes.

  • Domestic Engineering and Technical Support

    It has been developed in-house at MilSOFT since 2004, without reliance on external sources; under the terms of the contract, it provides access to the source code, auditability and local technical support.

    Goal: Licensing, updates, platform evolution and long-term support should be planned through a single accountable vendor.

The Difference

Why Mil-DDS?

How does Mil-DDS differ from other DDS applications?

DDS is an open standard defined by the OMG and implemented by various vendors. Therefore, the real question should not be ‘Should DDS be used?’, but rather ‘Which DDS implementation?’. An evaluation should consider standards compliance, architecture, platform support and long-term product continuity together. Mil-DDS implements the same standard through MilSOFT’s engineering and lifecycle management.

  • The standard is the starting point for architecture.

    OMG DDS and DDSI-RTPS are not an add-on compatibility layer, but form the core of the product.

  • It ensures long-term product continuity.

    Mil-DDS is developed by MilSOFT, which also manages its lifecycle; it offers a clear path for licensing, updates, platform evolution and long-term support. Source code access and auditability are provided under the contract.

  • It requires no central broker.

    Core data exchange runs directly between participants, removing the message broker as a single point of failure.

  • It grows with the mission.

    From point integration to multi-sector enterprise use, all based on the same architecture and the same codebase; no need to purchase again.

  • It protects the existing investment.

    It supports standards-based interoperability in heterogeneous DDS environments.

  • It covers the whole chain, end to end.

    Development, validation and runtime are all part of the same ecosystem; no link in the chain is outsourced to another product.

Use Cases

  • Command and Control Systems

    It enables real-time, reliable data sharing between the sensor, the command screen and the subsystems; critical command flows are prioritised using QoS.

  • ISR Systems

    It consolidates data from different sensors and platforms in a shared data space and reliably transmits it to the analysis and visualisation layers.

  • Embedded Platform Software

    With its operating model that does not perform dynamic memory allocation after start-up, it is used in embedded systems that require predictable timing.

  • System Integration Projects

    Components sourced from different tenders are integrated into the same network in a plug-and-play manner via a common ‘Topic’ abstraction.

Technology and Standards

Architecture

Software architecture
Publish-subscribe, data-centred, loosely coupled architecture; dynamic discovery of participants.
Transport layer
Flexible communication via UDP, TCP and shared memory.
Platform support
Windows, Linux, Embedded Linux, Solaris, QNX, VxWorks; x86/x86-64, ARM, PowerPC, SPARC.
Language support
C++, Java and C# APIs; type safety with platform-independent IDL and XML.
Dependencies
It does not require a central broker; core data exchange runs without any broker dependency.

Standards and Interoperability

OMG DDS / DCPS specification
Available
DDSI-RTPS (wire protocol)
Available
DDS-XTypes
Supported — the scope is defined on a project-by-project basis
RPC over DDS / Web-Enabled DDS
Supported — the scope is defined on a project-by-project basis
DDS Security
It is currently under development as part of the product roadmap — it is not available as an existing security feature

Who Is It For?

  • Decision-maker

    The freedom to scale the system as needs change, without being dependent on suppliers.

  • Systems Architect / Integrator

    Data-centric integration rather than writing point-to-point interfaces; new components do not break existing code.

  • Developer

    C++, Java and C# APIs; type-safe data modelling using IDL/XML; platform-independent development.

  • Operations / Maintenance team

    Architecture without a central broker — data is exchanged directly between participants; an outage of a single component does not stop the entire data flow.

  • Organisation

    A data layer based on open standards, auditable and developed in Türkiye; technological sovereignty.

An engineer wearing headphones, seated at a console in front of a wall of maps and radar screens

Next Step

Distributed systems. One shared data space.

Mil-DDS is a data communication layer developed entirely in Türkiye that enables critical systems to communicate with one another securely, in real time and independently. It scales from point integration to multi-sector enterprise use, utilising the same architecture and the same codebase.

There are two ways to evaluate Mil-DDS within your own architecture:

  1. 01 Technical assessment package Product documentation, QoS policy guide and sample data model.
  2. 02 Architecture workshop A half-day joint assessment of your current system architecture.