I ask my self is there an alternative to ROS2 out there. I found Bosch’s IoT Event Analytics (IoTea). First of all it chooses the V8 engine as its runtime. Due to one of my previous posts it seem to be a good choice to get an ISO26262 certification. The ROS2 appraoch is explained here.
Let us have a deeper look.
Processing units
ROS2 processing units are called nodes. In IoTea they call it talent. Both approaches can emit and consume messages. IoTea calls it event. In addition both also have an remote procedure call (RPC) like approach. ROS2 calls it service or action. In IoTea as well as ROS2 those calls can be non blocking (aka asynchronous).
ROS2 uses DDS as well as (implementation dependend) a shared memory interprocess communication approach. IoTea uses MQTT. DDS commonly uses UDP, broadcast like, based communication. MQTT uses a TCP based communication and requires a central brokering intance, managing topics. With DDS topics are a logic, not managed, communication “handle”.
Both approaches construct a processing graph. IMHO is a bit more flexible and dynamic in its management, because equal to ROS1 IoTea has central management units – but with a lower threat risk. IoTea calls it “ConfigManager”, managing a “FeatureGraph”.
Processing model
As from the afore mentioned graph, ROS2 manages “nodes”. In comparison Iotea manages “features”. A feaures is like a single data entity out of a ROS2 message. This implies that IoTea manages single datapoints, not “talents” as “node” equivalent. From a determinism perspective IMHO IoTea feels a bit more sustainable.
In additiont to the feeled determinism advantage, IoTea internally manage an hierachical algebrahic model of
- Subject as a matrices e.g., a vehicle
- Segment as multiple row vectors of a subject, described by an unique identifier (indention is to use a eClass number), e.g. the braking system
- Instance (only at runtime) as one row vector of a segment, e.g. a specific ECU
- Feature as one cell of a instance row vector, e.g., the tire speed
Subclauses:
- At runtime a message in IoTea represents a feature relating to an instance. At definition time feature relates to a segment.
- A feature can be a complex structure of multiple, semantical values. Internally it is a JSON object.
- IoTea allows an object oriented specialization of features. So called types build sub-classes of segments e.g. for a specific vehicle model.
- IoTea also gives e.g., a unit of measurement to each feature. Compare here.
Topic schema
As mentioned afore, both ROS2 and IoTea uses a publish-subscribe approach with a specific topic naming schema. Due to the following post IoTea describes its schema as follows:
< sharing mode >/< talent id >/< purpose >[/+]
Sharing modes are:
- < blank >, direct broker connection
- remote, connected via a broker bridging e.g. for failover
- ingestion, data that is coming from outside the platform and might not follow data schema
- configManager, for discovering purposes
Pruposes are:
- /events for passing messages
- /events/+ for distributed RPC
- /discover for discovering other participants
ROS2 does it according to the following article. IMHO ROS2 is better structured as IoTea. The topic naming is more expressive.
Overall IoTea makes use of the MQTT capabilities and ROS2 of the DDS given capabilities. Both makes it possible to perform record and replay. For IoTea the article here is the foundation. A tooling such as rosbag is not given. Furthermore ROS2 has clear advantage by its given clock and time abstraction.