Introduction
While typical software-defined vehicle architectures are all about integrating more functionality into fewer centralized compute units, networked communication across ethernet or CAN-based busses still plays a vital role in these “systems of systems.”
Our customers usually don’t start on a green field, which means applications implemented using Apex.Grace and Apex.Ida must be able to integrate into a larger environment and connect with legacy and external systems.
Our answer to this particular requirement is what we call connectors. On a high level, connectors are responsible for bridging the gap between those systems, both for the actual network communication and the semantic interface interoperability - which is required to make two systems understand each other.
In this blog post, we discuss the challenges that connectors face and how our new Apex.Ida middleware addresses them to deliver a highly flexible and performant communication solution to our customers.
Challenges
Connectors aren’t new to Apex.OS’ offerings and we’ve collected a lot of customer feedback and engineering experience in various customer projects over the past years. We’ve learned that connectors are a key feature for customers and have identified key challenges and requirements.
Dealing with existing interface definitions
Autosar XML, Franca IDL, DBC, Protobuf, OMG IDL, Thrift, DDL, …
The list of interface definition languages (IDLs) actively used in the automotive and robotics industries is long. Every OEM has a treasure trove of established interface libraries for series production models and pre-production use cases. Most importantly, these formats are usually part of established processes and customers expect to be able to continue to use familiar tooling to work with them.
Seamless integration of these existing signal, type and interface definitions is crucial to lower time to market and integrate into the existing ecosystem without forcing manual, time-consuming and hard-to-maintain conversion steps. Making this experience as seamless as possible is a key requirement.
The multitude of required protocols
Standards matter when it comes to communication. HTTP(S), TLS and TCP power this blog, MQTT and GRPC power the cloud and your car is likely powered by CAN and SOME/IP (and maybe Flexray).
A couple of protocols are a must-have for the industries Apex.AI is targeting. ROS compatibility calls for RTPS, the native transport protocol of DDS underpinning ROS 2. Automotive customers almost always require at least CAN, most also use SOME/IP. Maritime and robotics use higher-level protocols built on top of CAN, while cloud connectivity demands MQTT, Thrift and Google's GRPC.
However, we cannot implement every protocol stack for every target platform. Ensuring that existing non-ASIL implementations can be integrated safely into Apex.OS systems is thus critical.
Non-standard extensions
As if the many protocols listed above weren’t enough - non-standard extensions and variations exist and are actively used by our customers. Want to use SOME/IP on the wire but diverge from how messages are serialized in the standard? Sure! Does establishing a TCP connection in your system require a custom security handshake/key exchange before the standard protocol resumes? Absolutely!
Supporting these variants requires a flexible architecture with well-layered modules and composable interfaces.
Performance
No matter what protocol or input format is used, low overhead, good latencies and the highest possible runtime performance is essential for the systems our customers are building. We have designed our middleware with this in mind.
Apex.Ida Connectors
Architecture
Along with a shiny new middleware stack, Apex.Ida delivers a new connector architecture that addresses the challenges outlined above.
Connectors now plug directly into the core DDS middleware, extending its capabilities on the wire. Clean interfaces for de-/serialization and end-to-end protection of samples are used to interface with purpose-built pieces of code generated from intermediate models, as described below.
Most importantly, though, network/protocol traffic is separated out into dedicated gateway modules. These modules can be deployed into standalone processes, serving multiple applications utilizing the connector plugin.
Our safe zero-copy IPC mechanism is used to communicate with the gateway, bridging the gap between different criticality levels. Mixed-criticality IPC together with end-to-end message protection allows treating gateways as a black box, which in turn can mean that they remain QM-qualified, increasing the potential to reuse existing and proven protocol implementations without interfering with safety-critical applications.
With the new architecture, deployment decisions like “which topic maps to which native connector/protocol endpoint” are made using simple and readable configuration files for the gateway. Applications don’t even need to be recompiled when changing them.
IDL intermediate models
To avoid converting all sorts of user-type definitions to a real “lingua franca”, we introduced internal intermediate models. They serve as a target for various front-ends that each support one particular interface definition language and can extract the relevant information for the middleware needs.
All subsequent generation steps are based on these intermediate models instead of requiring adaptation for each input format. With this approach, existing source artifacts remain the single source of truth for our users.
SOME/IP
SOME/IP has long been one of the most important protocols to support. Compatibility with other AUTOSAR-based systems is crucial here, which is why we developed our own implementation of SOME/IP serialization – fully compliant with the specifications. As a result, our new Apex.Ida connector now has a lot fewer dependencies and better support for some of the more specific AUTOSAR serialization options.
Serialization is generated from our intermediate models, enabling the use of not just Franca IDL but also adaptive-style ARXML to describe interfaces and deployments for SOME/IP. Because of this flexible architecture, using SOME/IP for native Apex.OS applications, even using just ROS/OMG IDL, will become possible in a later release.
We also added support for various E2E protection profiles, as defined by the AUTOSAR standard. Combined with the adapted connector architecture and its plugin/gateway split, the vsomeip-powered gateway can be deployed into its own process, isolating it from safety-critical applications while ensuring the detection of corrupted messages.
Mapping SOME/IP events, methods and fields from and to DDS topics is now just one configuration entry away, with full-service discovery integration with the DDS middleware!
Other protocols
Apex.Ida pushes all network communication into gateways, which means that even DDS’ native protocol RTPS will become a connector. But also all existing Apex.OS connectors like CAN and MQTT will be ported to the new architecture and benefit from the new flexibility and improved performance. Stay tuned for the release announcements and more detailed posts in the future!
Conclusion
We’ve worked hard to address our customers' needs with Apex.Ida. Connectors are now in the perfect place to provide outstanding performance and high flexibility. With the intermediate model system, existing interface definition artifacts can remain the single source of truth. We have a lot more customization points available and will thus be able to offer a lot more features in the future.
Apex.Ida is the rock-solid foundation a middleware needs to be, ready to scale and become the basis for even greater frameworks.
If you are interested in Apex.AI products for your projects, contact us.