Apex.OS

Bundle of Apex.Grace and Apex.Ida

®

Apex.OS combines the ROS 2-based Apex.Grace software framework and Apex.Ida communication middleware into a software development kit for mobility, robotics, physical AI, and other embedded systems.

It provides execution, monitoring, and data transport services above the operating system. Customers build their application functions on these shared services instead of developing and maintaining a separate runtime and communication infrastructure for each project.

Certified to ISO 26262 ASIL B.

Extensive,ready-to-use feature set,
.

Easy migration from ROS 2-based prototyping to product development.

Apex.OS is used in diverse safety-critical applications across domains.

Apex.OS structure

Bundle

The bundle separates application logic from many details of the processor, operating system, and electrical and electronic architecture. This helps customers retain their investment in algorithms and interfaces as they introduce new hardware, integrate existing systems, or change how applications are distributed across electronic control units (ECUs). Function developers can work on application behavior while system architects configure execution and deployment for the target system.

Apex.OS supports development across passenger and commercial vehicles, off-highway machines, marine systems, and robotics. It combines a familiar ROS 2 development model with control over execution, memory use, and communication, helping customers apply existing skills to embedded-system requirements..

Customer
benefit

Apex.OS provides a common software foundation for software-defined vehicles and devices, helping customers turn each software investment into capabilities they can reuse across a product portfolio. Its modular architecture and interfaces based on open standards let internal teams and suppliers develop functions in parallel and integrate compatible components through defined interfaces.

By reusing application modules, communication services, and development practices, customers can reduce repeated infrastructure work, shorten development and integration cycles, and bring differentiated products to market sooner. Commonality across brands, vehicle classes, or machine families makes improvements available to multiple programs, while product-specific configurations and applications preserve differentiation.

The architecture can scale from functions on a single computer to applications distributed across multiple ECUs, allowing customers to adapt deployment as computing resources and performance requirements change. This helps manufacturers evolve their hardware strategy while retaining investment in application software. Over successive releases, teams can refine existing functions and add compatible capabilities on the same foundation, concentrating engineering effort on the behavior their customers value and reducing the need to maintain a separate software stack for every model or device.

Structure

Apex.Grace provides the application framework, C++ interfaces, execution and monitoring services, configuration, diagnostics, and development tools described in its product definition. It gives application teams a common model for implementing and managing software functions.

Apex.Ida provides communication libraries, shared-memory transport, protocol connectors, and interface importers described in its product definition. It connects application components with one another and with supported external systems through a common communication model.

The component user manuals, tutorials, and examples guide application development and integration, helping teams establish a shared implementation approach and onboard developers.

Execution control and resource efficiency

The Executor supports time-driven and data-driven execution, including configured trigger conditions, execution chains, and graphs. System architects can choose which work runs together and configure thread priorities and processor affinities. These controls help customers match application execution to incoming data and timing requirements, and reduce avoidable scheduling and context-switch overhead.

Safe containers and types, memory management resources, and generated C++ message types support applications that restrict dynamic allocation during operation. Apex.Ida zero-copy communication lets processes on the same machine exchange references to data in shared memory instead of copying each message between them. This can reduce CPU and memory-bandwidth consumption for data-intensive functions and leave more resources available for application processing. Actual latency and resource savings depend on the workload, platform, and configuration.

Monitoring diagnostics and system state

The ECU monitor and Execution monitor report resource usage and violations of configured liveliness, activation-rate, and runtime thresholds. The Event system, Node state management, Process manager, and System manager provide building blocks for responding to these reports and coordinating application states. Customers can implement a consistent approach to startup, shutdown, process recovery, and fault handling across application components.

Logging, the DLT writer, and UDS diagnostics help integration teams locate faults and relate them to system state through logs and diagnostic interfaces. The customer defines application-specific thresholds, state transitions, and responses; monitoring alone does not establish the required system response.

Application

development

and reuse

Application development and reuse — The C++ programming interface and ROS IDL interface provide a consistent way to define application nodes and their messages. ROS 2-compatible interfaces let developers apply existing knowledge and reuse compatible message definitions and tooling. This reduces the amount of project-specific infrastructure code and makes it easier for teams to exchange components through defined interfaces.

Architects can group nodes into processes or distribute them across ECUs independently of the application computation. Customers can adapt a software composition to new vehicle variants or computing platforms while limiting changes to algorithms. Reuse requires compatible interfaces and verification on the new target.

Communication and integration with existing systems

Publish-subscribe and request-reply communication provide common patterns for exchanging data between application components. Apex.Ida connectors support integration through DDS-RTPS, SOME/IP, and CAN, with interface importers for formats such as OMG IDL, AUTOSAR ARXML, Franca IDL, and CAN DBC. Customers can connect new applications to existing ECUs and AUTOSAR-based systems while retaining their established communication interfaces.

Application developers work with typed messages while connectors handle protocol-specific transport and serialization. Customers can introduce functions on a high-performance ECU and exchange data with existing controllers, supporting incremental modernization of the architecture. Supported quality-of-service settings configure communication behavior for the application. The Apex.Ida documentation defines protocol subsets and interoperability constraints

Recording replay and performance investigation

Data capture records messages for later analysis, and Deterministic fixed-order data replay can execute participating nodes in a configured order with defined input data. Together with Simulation time, this allows teams to bring recorded system behavior back to the development environment, investigate defects, and repeat integration tests without recreating every condition on the physical machine. Fixed-order replay requires the documented Executor integration and a suitable system-under-test configuration.

Tracing exposes latency, data flow, and resource use, helping customers identify bottlenecks and compare deployment configurations. Tracing is supported on Linux. Specialized validation workflows and integrations are described separately in Apex.OS for Verification & Validation.

Configuration and reproducible builds

Settings, Parameters, and Message storage support the configuration and persistence of application data such as calibration values. They allow teams to manage deployment differences without embedding every variant in application logic. The permitted use of dynamic configuration depends on the development phase and component documentation.

The Bazel-based Hermetic build toolchain supports reproducible builds and caching. Customers can reproduce an integration baseline, investigate build differences, and reduce repeated compilation work. A controlled baseline makes changes easier to review and validate across teams.

Apex.OS

Bundle of Apex.Grace and Apex.Ida

®

Apex.OS is used in diverse safety-critical applications across domains.

Apex.OS structure

Customer benefit

Customer
benefit