Automotive Middleware
Production automotive middleware.
Middleware integrating SOME/IP, DDS, IPC and Ethernet enabling scalable Software Defined Vehicle architectures. We design service-oriented communication layers that connect ECUs, high-performance computers and cloud backends. Our work covers service discovery, serialization, QoS tuning and gateway design between protocol domains. Built for AUTOSAR Adaptive and Linux-based vehicle platforms.
Automotive middleware is the communication layer that sits between individual ECUs, domain controllers and a vehicle's high-performance computer, using SOME/IP or DDS over Ethernet so software components can call services and exchange data without hard-coding point-to-point links. It includes service discovery, serialization, QoS tuning, TSN/gPTP time sync and the gateway logic that bridges CAN, SOME/IP and DDS domains on AUTOSAR Adaptive or Linux platforms.
- SOME/IP service design, service discovery and vsomeip-based stacks
- DDS data-centric communication with tuned QoS profiles
- Protocol gateways bridging SOME/IP, DDS, CAN and IPC domains
- AUTOSAR Adaptive platform integration and ara::com bindings
- TSN/gPTP time synchronization and Automotive Ethernet network validation
1. Discovery
We map your requirements, constraints, existing systems and success criteria before proposing a solution.
2. Architecture
We design the system architecture, interfaces and technology choices, documented and reviewed with your team.
3. Implementation
We build in short iterations with working increments, code review and continuous integration from day one.
4. Validation
We test against real conditions — hardware, load, failure modes — and report measured results, not assumptions.
5. Deployment
We ship to production with monitoring, documentation and a handover that leaves your team in control.
Where benchmarks are required, Gengini documents throughput, latency, test platform, workload, and measurement method.
Technologies
- Middleware architecture specification and interface definitions
- Working communication stack integrated on target hardware
- Protocol gateway components with conformance tests
- Latency and throughput benchmark report
- Integration guide for application teams
Should we use SOME/IP or DDS?
It depends on your architecture. SOME/IP fits AUTOSAR-aligned request/response and service discovery patterns; DDS fits high-rate data-centric distribution with fine-grained QoS. Many vehicles use both with a gateway, and we help you draw that boundary.
Do you work with AUTOSAR Adaptive?
Yes. We integrate middleware with AUTOSAR Adaptive platforms including ara::com service bindings, execution management and deployment manifests, as well as with plain Embedded Linux stacks.
Can you debug an existing SOME/IP deployment?
Yes. We troubleshoot service discovery failures, multicast issues, serialization mismatches and latency problems using packet capture, tracing and targeted instrumentation on the target.
Why does SOME/IP service discovery fail in Docker or over a switch?
Almost always the network underneath, not the SOME/IP stack — Docker's default bridge silently drops multicast, and unmanaged switches or firewall rules can do the same. We diagnose this with packet capture at each hop before touching application code.
Do you work with NXP S32G or similar automotive network processors?
Yes. We integrate middleware stacks on S32G-class hardware and similar Ethernet-switch-plus-application-core SoCs, including TSN/gPTP configuration on the switch side.
How do you validate middleware performance before production?
We benchmark latency and throughput on the real target hardware and network topology, not a developer laptop, and report the test platform and workload alongside the numbers so results are reproducible.
SOME/IP vs DDS: Practical Comparison for Automotive Middleware
A practical engineering comparison of SOME/IP and DDS for automotive middleware, SDV platforms, and service-oriented architectures.
DDS vs MQTT vs SOME/IP: Choosing the Right Communication Middleware
A decision framework for choosing between DDS, MQTT, and SOME/IP based on topology, QoS needs, and deployment constraints.
How to Design a Simple SOME/IP Service Discovery Demo
A step-by-step implementation guide for building a minimal SOME/IP service discovery demo using vsomeip on Linux and QEMU.
Embedded & Firmware Engineering
Custom Linux BSPs, RTOS firmware and reliable hardware interfaces.