IDL Importers – Speaking Every Language Your System Needs

In high-performance software environments like automotive, robotics, and industrial automation, it’s common to encounter a wide mix of technologies, and just as many ways to describe data. Whether it’s a legacy CAN system, a DDS-based robotics stack, or an AUTOSAR Adaptive ECU, every platform speaks its own "interface language." 

To bridge these diverse systems, Apex.Ida introduces a powerful IDL Importer Framework—allowing you to work with the standards and tools your projects already use, while benefiting from Apex.Ida’s unified communication model. 

This is the third installment in our Apex.Ida feature series. In this post, we explore how Apex.Ida helps you manage and integrate a wide range of Interface Definition Languages (IDLs) through a clean, extensible architecture. 

Apex.Ida IDL Importers

The Challenge of Interface Diversity 

Different domains—and sometimes even different teams—rely on different IDLs to define message structures, services, and communication APIs. From OMG IDL in DDS systems, to ROS IDL, AUTOSAR ARXML, Franca IDL, and CAN DBC, each format reflects its domain’s unique history and priorities. 

And in modern system development, you rarely work with just one. Integrating legacy software, coordinating across suppliers, or moving from prototype to production often means juggling multiple IDLs simultaneously. 

A Unified Type Model 

The Apex.Ida IDL Importer Framework solves this by translating diverse interface definitions into a unified internal type model. This internal model acts as a bridge between frontends (which parse the original IDL files) and backends (which generate serialization and gateway code for specific network protocols). 

This frontend-backend separation means developers can: 

• Reuse existing IDL files without rewriting them 

• Target different transports (e.g., DDS, SOME/IP, CAN) from the same source definition 

• Stay aligned with upstream ecosystems like AUTOSAR, ROS 2, and DDS 

Let’s take a closer look at the supported formats. 

Supported IDLs in Apex.Ida 

OMG IDL 

The Object Management Group's IDL has long served as the foundation for DDS and CORBA-based systems. It's also used in ROS 2 and is the default interface definition language for Apex.Grace nodes. 

By using OMG IDL, developers can define an entire Apex.Ida system’s communication structure in a format that is both future-proof and widely supported. It is especially well-suited for seamless integration with the DDS-RTPS Connector. 

ROS 2 IDL 

While built on a subset of OMG IDL, ROS 2 IDL adds domain-specific conventions, including .msg and .srv files for topics and services. Apex.Ida supports this subset out of the box and extends it to accommodate advanced integration use cases—such as bridging to AUTOSAR-based systems or enhancing compatibility with SOME/IP stacks. 

This flexibility allows Apex.Grace developers to maintain ROS 2 compatibility while preparing for production-scale deployments in automotive and industrial contexts. 

ARXML 

AUTOSAR’s ARXML format is a central pillar of automotive software architecture. While it can describe full systems, Apex.Ida focuses on extracting: 

• Signal and service definitions for CAN and SOME/IP 

• Gateway configuration parameters for protocol bridging 

This support enables direct integration with AUTOSAR ECUs, turning ARXML files into actionable interface definitions within Apex.Grace and Apex.Ida. 

Franca IDL 

Widely used in early-stage SOME/IP development, Franca IDL offers a clean, AUTOSAR-independent way to define communication interfaces. Apex.Ida supports both .fidl files (methods, events, fields) and .fdepl deployment files for gateway configuration. 

This makes it easier to start system integration even before full AUTOSAR models are available, bridging the gap from prototype to production. 

DBC 

DBC files are simple, lightweight, and widely adopted. They are a practical way to define CAN messages and signals in early-stage or non-AUTOSAR environments. Apex.Ida includes a dedicated DBC importer that parses these files and generates the deserialization logic required by the CAN Connector backend. 

Whether you're working with raw CAN frames or signal-level messaging, DBC support helps you move forward in your development process. 

Built for Integration at Scale 

By embracing the diversity of interface formats used across real-world projects, Apex.Ida’s IDL Importer Framework enables: 

• Rapid onboarding of legacy systems 

• Cross-supplier collaboration with minimal friction 

• Protocol flexibility without duplication of effort 

• Seamless integration into domain-specific ecosystems 

This approach empowers teams to use the best tool for each phase of development—without sacrificing the consistency and performance benefits of the Apex.Ida middleware stack. 

One Middleware, Many Languages 

From signal-level CAN messages to DDS topics and cloud service calls, Apex.Ida brings it all together. With the IDL Importer Framework, your team can work with familiar formats, simplify integration across domains, and accelerate development without compromise. 

Want to See It in Action? 

If you're juggling multiple IDLs in your architecture—or planning a system integration effort—Apex.Ida can streamline the process. Contact our team to learn more or request a tailored demo.