RTI Connext DDS 5.0.0 provided limited support for type evolution by implementing Extensible type extensibility as defined in the “Extensible and Dynamic Topic Types for DDS” specification, commonly referred to as the DDS-XTypes spec.
With Extensible type extensibility, the types in a DDS system can evolve by adding new elements at the end.
For example, let’s assume a GPS vehicle tracking system. In a first implementation, the VehicleData type may provide position information such as latitude and longitude:
In a second implementation, the vendor may decide to add speed as part of the VehicleData information. Without a way to evolve the types, the devices that subscribe to vehicle data without speed will not be able to interoperate with vehicles publishing vehicle data with speed. Likewise, new devices that read vehicle data with speed will not interoperate with vehicles that do not publish speed data.
By adding Extensible extensibility support to Connext DDS both versions of the type can coexist in the same system:
Notice that the VehicleData type evolved by adding the speed at the end.
In a third version of the system, the vendor may decide to track not only ground vehicles but also air vehicles. In order to do that, the Position type has to evolve to include altitude as follows.
This kind of evolution is not supported by Extensible extensibility because VehicleData_v3 has not been evolved from VehicleData_v2 by adding new members at the end but by changing the structure of the common member position.
However, RTI Connext DDS 5.1.0 does support this kind of evolution with Mutable extensibility. A mutable type can evolve by adding, removing or changing the order of the members as long as the common members are compatible with each other.
In this system, the mutable type VehicleData_v3 is compatible with VehicleData_v2 because the types Position_v1 and Position_v2 are also compatible by applying the Extensible extensibility rule that allows adding a member to the end.
By adding support for Mutable extensibility we can have a system in which new and old components can exchange VehicleData. However, some of the data exchange may lead to semantic errors. For example, let’s assume a reading device such as an iPad that visualizes VehicleData_v3 data (with altitude). If the device receives data from a vehicle publishing VehicleData_v2 (without altitude) the altitude value will be set to a default value of zero. However, this is misleading because zero is a valid altitude value. Are we looking at a vehicle with zero altitude? Or a vehicle that does not provide altitude?
To resolve these kinds of ambiguities, RTI Connext DDS 5.1.0 introduces support for optional members. Optional members are modeled after nullable columns in SQL. When a member is marked as optional it can be assigned a NULL value, which means that either the value is not known or it does not exist.
Supporting mutable types and optional members in RTI Connext 5.1.0 is a game changer when it comes to system interoperability. System evolution is unavoidable and the world cannot stop to adapt to it. RTI will continue incorporating additional features from the DDS-XTypes specification in future releases to support complex use cases. For additional information, please consult the RTI Connext 5.1.0 documentation. If you have any questions, visit community.rti.com to search our Knowledge Base and post your questions in the forum.
Note: The author of this post is Fernando Crespo Sanchez. Lacey published it for him as a favor since he doesn’t have a WordPress account at the moment.