Eclipse Kanto is a broadly-focused IoT platform. Kanto currently is missing automotive-specific capabilities required for broad adoption in the automotive and commercial vehicle segment.
Eclipse Kanto is an ideal match for the IoT software stack for the Commercial Vehicle edge device market.
This proposal requests to consider adding automotive extensions that enable CAN communication. For Commercial Vehicle (and Automotive in general), the focus would be standardized and secure CAN datalink access extensions and standardized application interfaces and message formatting extensions.
Cummins has developed a solution that translates the J1939 and UDS CAN protocols over MQTT. Eclipse Kanto is a modular IoT edge software that provides the IoT architecture for running this protocol translator. Cummins is seeking to contribute J1939 and UDS translator services to Eclipse Kanto so that it can meet the automotive industry specific needs for CAN communications and security.
Kristiyan Gostev, one of the main developers of Eclipse Kanto, has recommended to create a project for Eclipse Kanto Extensions for Automotive, which would include the components we (Cummins, Inc) intend to contribute, namely J1939 and UDS communication and security management over CAN.
Eclipse CANought provides extensions to the Eclipse Kanto project focused on automotive market segment capabilities by standardizing and securing CAN communications. Eclipse CANought contributes the J1939 and UDS translator services to Eclipse Kanto and thus meets the automotive industry specific needs for CAN communications and security.
In-scope
- CAN Security Manager: manages CAN access and bandwidth allocation for balancing utilization across multiple applications
- MQTT APIs for J1939 and UDS communication in a well-documented format using the AsyncAPI specification
- Boilerplate Docker files, such as
- A Dockerfile for a Visual Studio Code Dev Container
- A Dockerfile for google unit tests, MQTT interface tests and static code analysis
- A Dockerfile for building the final application
- A Docker Compose file for running the application
- Boilerplate C++ code and helper files for a) The J1939 and UDS client application and b) The J1939 and UDS Translator service such as
- CMake files
- Application initialization code
- Functions/methods for J1939 and UDS MQTT API Calls
- Functions/methods for J1939 and UDS Message Handlers
- A J1939 and UDS Translator Validator for validating that a given implementation of the J1939 and UDS Translator MQTT APIs are implemented correctly
- Possibly, code generators, to automatically generate the boilerplate C++ code or Rust code for both the Translator client and the Translator server
Out-of-scope
- An implementation of the J1939 and UDS libraries themselves is out-of-scope. The J1939 license does not permit open source implementations of the J1939 specifications or stack.
Eclipse CANought offers the automotive-specific capabilities to enhance the Eclipse Kanto project to offer a comprehensive solution focused on the automotive industry. Eclipse CANought provides extensions to the Eclipse Kanto project focused on automotive market segment capabilities by standardizing and securing CAN communications.
It is critical that Automotive IoT applications have a standardized and secure solution for CAN communications with embedded controllers. The Eclipse CANought extensions will make Eclipse Kanto more appropriate for automotive-focused implementations.
None.
With this project, we are hoping to bring the following values.
- Industry Standardization to unify application APIs. There are numerous CAN protocol libraries that all have different API specifications. This requires applications to be customized to work with each library. This project allows any telematics applications to be written once for the open source API and work with any CAN library that adopts the open source spec.
- Reduced Time to Market. Providing components which aid in the reading of CAN data will accelerate the development and delivery for companies developing Automotive applications that run on Eclipse Kanto.
- Reduced Cost. Providing these components as open-source will reduce the development costs for application developers using Kanto.Auto due to standardized APIs and client libraries that expedite development.
- Community Collaboration. Combining our SDV knowledge and capabilities with other companies in this space to enhance the overall automotive capabilities and enhance Eclipse Kanto.
- Community Growth. This project will be Cummins’ first open-source project. Having more active code contributing companies will help grow the Eclipse Open-source Community. Cummins works with numerous automotive companies and will drive new engagements and bring on new contributors.
- Kanto CAN Translator – Code for sending and handling J1939 and UDS MQTT messages (Note to Cummins team. Since this would need to come from KPIT, not sure if we should add it here yet)
- C++ code generation for asyncapi, to ease the creation of the boilerplate code of the J1939 and UDS client and server. This will help to make updates to the client and server boilerplate code easily whenever there’s an update to the API specification.
- Rust code generation for the same
- CAN-FD
- Autosar protocol translator
- Kuksa.val Data Broker Integration (VSS messages)
Tentatively
- Ready for contribution – Subproject 1 – kanto-can-translator-client-template – Initial contribution. Initial build ready with unit tests.
- Ready for contribution – Subproject 5 – kanto-can-governor – Initial contribution.
- Ready for contribution – Subproject 2 – kanto-can-translator-api – J1939 and UDS Translator API documentation
- Ready for contribution – Subproject 1 – kanto-can-translator-client-template – Addition of J1939 messages over MQTT for Project 1
- Jun 2024 – Subproject 3 – kanto-can-translator-validator – Code for validation of UDS messages
- Jun 2024 – Subproject 3 – kanto-can-translator-validator – Code for validation of J1939 messages
- July 2024 – Subproject 5 – kanto-can-security-manager – First beta release of CAN Security Manager
Individuals
- Guru Prasad A S - BGSW / Bosch
- Kai Hudalla – Bosch Digital
- Carlton Bale – Cummins
- Martin Brown - Cummins
Companies
- Cummins
- BGSW
- Bosch Digital
- KPIT
The first contribution will consist of one subproject.
- J1939 and UDS Translator client template project, containing
- Dockerfile for a Visual Studio Code Dev Container
- Dockerfile for google unit tests
- Dockerfile for building the client application
- CMake files for building the source
- C++ header and source files for application initialization and for sending J1939 and UDS requests over MQTT
- Code codeveloped by Cummins and KPIT
The second contribution will consist of another subproject
- CAN Security Manager, containing
- Source code for the CAN Security Manager with basic functionality such as CAN bandwidth limitation. Additional security features will be contributed later as the project matures.
- Source code for the C++ client library for the CAN Security Manager
- Source code for Unit Tests
- Code developed by Cummins
Third party libraries.
- Eclipse Paho MQTT C++ Client Library (Eclipse Public License - v 2.0)
- Nlohmann JSON library (MIT License)
- Log in to post comments
Some additional comments from me
Submitted by Kristiyan Gostev on Wed, 03/27/2024 - 02:59
Eclipse Kanto™ is a modular IoT edge software that enables devices for IoT with all essentials like cloud connectivity, digital twins, local communication, container management, and software updates - all configurable and remotely manageable by an IoT cloud ecosystem of choice.
Eclipse Kanto makes it possible to deploy intelligence on the device so companies can get more value from diverse edge assets, process and act on IoT data right on the device and manage devices from the cloud. Device manufacturers can add new revenue streams with connected products and ensure agile development for hardware and software.
Using Eclipse Kanto, technology teams take advantage of configurable and reusable building blocks to connect the unconnected or build the edge applications for the next generation connected products and services.
Eclipse Kanto is specifically optimized for complex IoT devices facing limited hardware resources, (near) real-time requirements, diverse device software, heterogeneous data sources and the ability to operate without connection. This makes it a perfect technology for emerging paradigms such as software-defined vehicles, connected machines and connected manufacturing, smart appliances, smart buildings and more.
The goal for Eclipse Kanto is to be an industry independent, general purpose IoT Platform, however as the projects gains popularity, demand for new components that are specific only for a single industry, for example SDV, robotics, etc., is growing. So, there are now several challenges:
1. Preserve the industry agnostic purpose of Eclipse Kanto.
2. Support industries to build solutions around Eclipse Kanto.
3. Support open sourcing industry specific components that are build around Kanto's ecosystem.
4. Maintain industry specific components in an open source environment.
As an extention to Eclipse Kanto this addon and its components should have the following characteristics:
1. Eclipse Project called `Eclipse Kanto Addon for Automotive`.
- This naming says that this software component is part of the Eclipse Kanto ecosystem and will eliminate confusion.
- This will preserve Eclipse Kanto's core as an IoT independent platform and in the same time enable the addon for unlimited growth in its domain.
- There will be no conflicts between the different industry representatives about what needs to be included in Kanto and what not.
2. Driven by the industry experts.
- Industry specific components must be driven by the experts in that field as they know best what is trending and what is missing.
- This will enable the team working on the addon to chose technologies that might be suitable only for their domain, which might not make sense to be used in the core Kanto.
3. Implemented following the industry standards combined with the Eclipse Kanto's architecture.
- The addons should follow the best practices and architectural guidelines that Kanto brings. For example:
- Digital twins using the Eclipse Ditto specification.
- Meta layer with Yocto recipes.
- Update Agents for specific domains using Kanto's `update-manager` APIs
- MQTT for local communication
4. Documented by the industry experts and hosted or referenced by https://eclipse.dev/kanto under an addon section.
- The addons are part of Kanto, so it makes sense that they will use the same website for documentation.
- All addons should be linked in the Eclipse Kanto documentation and should be visible in the website.
- How to guides like `Enable Kanto for Automotive`, etc could be added in the documentation.
5. Follows independent release schedule from Eclipse Kanto.
- Even though the addons are part of Kanto, they will be still independent enough to have own release roadmap.