Communication Module: mw::com (with multiple bindings including LoLa), memory::shared, and message_passing

High-performance, safety-critical communication middleware for automotive safety standards up to ASIL-B with:

• Multi-Threading Support: Thread-safe operations with atomic data structures
• Multi-Platform: Supports Linux and QNX operating systems

Overview

The module consists of three components (also known as safety elements out of context (SEooC)).

1. LoLa/mw::com (High-Level Middleware)

The mw::com (also known as LoLa - Low Latency) is an open-source implementation that provides:

This provides zero-copy, shared-memory based inter-process communication (IPC) in embedded systems.

• Service Discovery: Automatic service registration and discovery
• Event/Field Communication: Publish-subscribe messaging patterns
• Method Invocation: Remote procedure call (RPC) support
• Quality of Service: ASIL-B and QM (Quality Management) support
• Zero-Copy: Shared-memory based data exchange for minimal latency within ECUs
• Tracing Infrastructure: Zero-copy, binding-agnostic communication tracing support

2. Message Passing (Low-Level Foundation)

• Asynchronous Communication: Non-blocking message exchange
• Multi-Channel: Multiple senders to single receiver communication (unidirectional n-to-1)
• OS Abstraction: POSIX and QNX-specific implementations

3. Shared memory abstraction (Low-Level Foundation)

Getting Started

Prerequisites

• C++ Compiler: GCC 12+ or Clang with C++17 support
• Build System: 8.6 <= Bazel < 9.x (only with Bzlmod)
• Operating System: Linux (Ubuntu 24.04+) or QNX
• Virtualization: Docker with user permissions or rootless mode

DevContainer Setup(Recommended)

Note: This repository offers a DevContainer. For setting this up and enabling code completion read eclipse-score/devcontainer/README.md#inside-the-container.

Note: If you are using Docker on Windows without WSL2 in between, you have to select the alternative container eclipse-s-core-docker-on-windows.

Building the Project

See CONTRIBUTING.md.

Project Structure

communication/
├── score/mw/com/  # Main communication middleware (design,code,tests,examples)
├── third_party/   # External dependencies
├── bazel/         # Build configuration
└── BUILD          # Root build file

Documentation

For Users

• User Guide - Getting started with the API
• API Reference - Detailed API documentation
• Tutorial - Guided user-facing API walkthrough

For Developers

• Architecture Guide - System architecture overview
• Service Discovery Design - Service discovery implementation
• Message Passing Design - Low-level messaging details
• Safety Requirements - Safety assumptions and requirements

Contributing

We welcome contributions! See our Contributing Guide for details.

Release model

Versioning

This repository follows Semantic Versioning.

Cadence

As of today, there is no fixed cadance on how often we publish a new release. If you need a new release, or a bug fix of a previously published release without new changes, please create an issue.

Distribution

Releases are available in the GitHub releases page of this repository and published as a Bazel module in the Eclipse S-CORE Bazel registry.

Safety qualification

The safety qualification of the different SEooCs is not provided but we strive to provide the necesary safety artifacts required for a safety qualification. We do that by making use of S-CORE tooling.

The artifacts can be found in:

• Quality reports
• Individual components documentation
  • mw::com
  • message passing
  • shared memory

Support

Community

• Issues: Report bugs and request features via GitHub Issues
• Discussions: Join community discussions on the Eclipse forums
• Documentation: Comprehensive docs in the design/ and doc/ directories

Flaky tests

Non-deterministic behavior is not desired in safety critical systems. The first step to prevent and fix such behavior, is to be able to detect it.

Because of that, the tests of this project are run every night multiple times to detect such behavior. Any thest that sometimes passes and sometimes failes is considered a flaky tests and an issue is created automatically.

A test migh be flaky for different reasons. The non-deterministic behavior could come from the software but also from the test itself or the infrastructure. For this reason, if you suspect non-deterministic behavior in the software comming from this project, please create a separate issue even if it might be already reported by one of the automatically created tickets. The analysis of user created issues about non-deterministic behavior will be prioritzed over the automatically created issues.

---

Note: This is an open-source project under the Eclipse Foundation. It implements automotive-grade communication middleware suitable for safety-critical applications.