Authors: Kevin Goez and Lyle Johnson
We are thrilled to announce the release of the Apex.Ida CAN Connector — packed with cutting-edge features to elevate your connectivity experience. The CAN (Controller Area Network) bus is used between microcontrollers and microprocessors in today’s modern vehicles and vessels. It’s designed for lower bandwidth and higher frequency communication between systems. Because there are dozens and, in some cases, 100s of these sub-systems in a single vehicle, it is essential to have a future-proof middleware solution that offers interoperability with the status quo.
The CAN Connector proves that the connector (network) architecture we revealed in December (https://www.apex.ai/post/connectors-and-our-idl-framework) is both highly valuable and necessary. Creating a malleable software function with the highest performance expectations and requirements is challenging. With the appropriate architecture, this CAN Connector is feature-rich and able to handle the (data) payload and (architectural) complexity required for today’s passenger vehicles, tractors, marine vessels, and other robots. The post above details the architecture; here, we will share information that application developers and system integrators are keen on knowing to design and implement robust and configurable robotics systems.
With Apex.Ida, a singular application-facing API has emerged, unifying diverse protocols and buses with the recent addition of CAN. This unified API serves as a gateway, allowing components to seamlessly transition from standalone microcontrollers to robust, high-performance computers without necessitating alterations to their underlying implementation. Instead, shifting transport mechanisms from CAN to any other optimal transport mode tailored to the evolved architecture becomes a straightforward endeavor. This flexibility streamlines the development process and future-proofs the system against technological advancements.
Be all you CAN be
1. Full protocol support
There are various commercial and open-source solutions for a basic CAN connector. However, our customers need all the bells and whistles—we support CAN-FD and Extended CAN IDs to provide complete protocol support for the latest standards. The CAN Connector natively supports the management of multiple CAN channels (within the same connector instance). This allows developers to design elegant solutions and manage the system's complexity because they can avoid having 100 connector instances for 100 CAN channels.
2. Enhanced configuration capabilities
Most of today’s systems have 100s of CAN signals, and more than a few have 1000s of CAN signals. Managing each CAN Connector by manually writing the code to get/set the data transmitted via CAN signals is infeasible. That is why we added methods to configure the CAN Connector (and the relevant CAN channels) by using industry-standard DBC (Database CAN) and ARXML (Autosar XML) files. To simplify configuration management, the CAN Connector supports multiple input files per channel and provides full CAN signal multiplexing—this further reduces the effort required from a developer to integrate a new CAN-based sensor or hardware device (like an actuator).
3. Efficient multiplexing
Writing the logic to get and set the values in multiplexed messages is tedious and error-prone. This is why we’ve introduced the multiplexing helper classes to take the difficult work of handling the message layout away from the developers, making their lives easier and allowing them to focus on the task at hand. Using the multiplexing helper classes guarantees that the message layout will be correct (as defined in the DBC file). Developers then use the convenient and error-free approach to read and write multiplexed CAN messages.
4. Simplified integration
There are more opportunities for developers to inadvertently introduce error—handling generated constants. The most common approach is for developers to manually define their contents with binary values. This is a lot of work, and it is easy to use the wrong constants in a given field unknowingly. To mitigate this, Apex.Ida and the CAN Connector generate the constants as fully namespace-qualified constants directly mapped to the signal namespaces. This makes the generated constants error-proof, and the chances of a developer incorrectly writing the wrong value to a given signal are minimized. In addition, the CAN Connector configuration requires that the developer explicitly name the messages their application will use to communicate, which means they must know what they add to the configuration. No implicit decisions have been made by the code generators or the CAN Connector. This prevents CAN ID collisions and the unintended behavior that accompanies those collisions.
5. Enhanced functionality
If you already have application code (C++) to process incoming CAN data, the CAN Connector is configurable to pass (raw) CAN frames to those applications, expanding the possibilities of your connectivity solutions. This seamless integration allows developers to focus on exciting and challenging problems and spend as little time integrating new sensors, systems, and hardware as necessary.
6. Robust testing and build environment
Like for all Apex.Ida APIs we provide and code we write, we provide high code test coverage to ensure production quality levels of stability for your applications. Vehicle programs and developers who already leverage Bazel for their build system and environment hit the ground running with full velocity because of our native Bazel support.
7. E2E protection
Every middleware component needs to leverage security and data integrity modules, so the CAN Connector includes end-to-end protection through integration with the Apex.Ida E2E module. This allows the connector to detect and discard incomplete or tampered data.
8. Seamless integration with Apex.Grace
The Apex.Ida CAN Connector has native integration with Apex.Grace—this is the fastest way to integrate a new CAN-based device and immediately begin accessing and processing the data it produces (or sending data that the CAN-based device consumes). CAN data can also be processed and handled at the Apex.Ida layer if the developer chooses to. We designed this connector so developers can control where they handle the CAN data.
You CAN do it
The new Apex.Ida CAN Connector sets a new standard for connectivity solutions, empowering you to innovate confidently. Upgrade now and unlock the full potential of your connectivity infrastructure.
If you are interested in Apex.AI products for your projects, contact us. We’re always looking for talented people to join our international team. Visit our careers page to view our open positions.