Module Gateway

Directory contains cpp implementation of module gateway that communicates with internal client and external server. Module Gateway is one component of Fleet protocol.

Module Gateway is composed of:

Internal Server

The internal server handles the connection and incoming data from the Internal Clients (devices). After verification the data are parsed into protobuf message that is sent to Module Handler. Internal server then receives response to the message and sends it back to Internal Client.

Module Handler

The module handler is responsible for receiving protobuf messages from internal clients via the internal server. It processes these messages using the status aggregator and subsequently sends corresponding commands back to the internal client. Each status aggregator holds information about the connected internal client, including aggregated statuses, commands, and the actual status. The external client updates the command for each connected device and subsequently transmits the aggregated messages to the external server.

External Client

The external client is responsible for initializing connection with external server, reconnecting, delivering protobuf messages from module handler to external server and updating devices commands. It uses error aggregator to process messages which could not be delivered, when connection is broken and as soon as the connection is up, then error aggregated message is sent.

Requirements

• cmlib

• protobuf

• cxxopts

• boost

• nlohmann-json

• pahomqtt

• pahomqttcpp

• zlib

• ba-logger

• fleet-protocol-interface

• fleet-protocol-cpp

• aeron

• async-function-execution

• g++ >= 10 or other compiler with c++23 support

For exact dependency versions used in the build, see cmake/Dependencies.cmake.

Build

mkdir -p _build && cd _build
cmake ../ -DCMLIB_DIR=</absolute/path/cmakelib>
make

Run

./module-gateway-app --config-path=../resources/config/default.json

Connecting a device module to a cloud external server

Each module the gateway carries needs its plugin in module-paths and its number listed in the endpoint's modules; a module with no endpoint is logged as Module with number: N does not have endpoint, so skipping this module and its devices are then refused with DeviceConnect rejected. external-connection.vehicle-name must match a car the external server has configured, or the server answers Received Connect message for unknown vehicle.

For the teleoperation streaming-control path that means module 3 (transparent) in both places, a QUIC endpoint pointing at the external server's vehicle leg, and its mTLS material in quic-settings — see QUIC Example and the config README.

Arguments

• Required arguments:
  • -c <string> | --config-path=<string>path to json configuration file (Configs Readme)
• All arguments:
  • -h | --help print help
  • --port=<unsigned short> port on which Internal Server communicates

CMAKE arguments

• CMLIB_DIR=<PATH>

• BRINGAUTO_TESTS=ON/OFF

  • DEFAULT: OFF
  • if on enable build/configure of tests
  • if off disable build/configure of tests

• BRINGAUTO_INSTALL=ON/OFF

  • DEFAULT: OFF
  • if on enable install feature,
  • if off disable install feature,

• BRINGAUTO_PACKAGE=ON/OFF

  • DEFAULT: OFF
  • if on enable package creation - if the BRINGAURO_INSTALL is not ON then is switched ON with warning,
  • if off disable package creation

• BRINGAUTO_SYSTEM_DEP=ON/OFF

  • DEFAULT: OFF

• BRINGAUTO_MODULE_GATEWAY_MINIMUM_LOGGER_VERBOSITY=DEBUG/INFO/WARNING/ERROR/CRITICAL

  • DEFAULT: DEBUG
  • sets the minimum logger verbosity on compile level to improve performance

• CURRENTLY UNUSED

  • BRINGAUTO_SAMPLES=ON/OFF
    • DEFAULT: OFF
    • if on enable build/configure of sample aplications
    • if off disable build/configure of sample application

Tests

Tests Readme

Memory leaks

It is possible, that valgrind will show you, that there are still reachable memory leaks. It is caused by dlopen function. We are not sure, if bug is in dlopen or in valgrind, but we cannot do anything with that. The bug is already reported.

Dockerfile

Port 1636 is exposed in the dockerfile.

Building the image outside CI currently fails in the first stage with CMCONF[FLEET_PROTOCOL] - Cannot find configuration for system 'FLEET_PROTOCOL': nothing in the Dockerfile supplies the FLEET_PROTOCOL CMCONF configuration that CMCONF_INIT_SYSTEM requires, and the bringauto/cpp-build-environment:latest base does not carry it. Build from source for now.

Published images vs. QUIC

The images published to Docker Hub up to and including v1.3.4 are MQTT-only — they reject a QUIC endpoint at startup with Invalid protocol type: "QUIC". Talking QUIC to an external server therefore needs a build from source of a version that supports it.