Create Industry-specific Extensions for Kanto

[carltonbale]

Kanto is an ideal match for the IoT software stack we need for the Commercial Vehicle edge device market. I understand that Kanto is intended to be a generic set of capabilities that work across industries. It would be great if Kanto had the option to have thoughtfully-integrated, industry-specific capabilities that could be optionally included as needed.

This is a formal request to consider adding industry-specific extensions that enable industry-specific contributions. 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.

[k-gostev]

Hi @carltonbale. thank you for this proposal. As you stated Kanto is indeed intended to to provide IoT platform that suites variety of different industries, and as such, our goal was always to keep Kanto industry agnostic. For this I would like everything in https://github.com/eclipse-kanto/ to remain that way. My idea is to preserve eclipse-kanto as a core component.

However, I see your point and I also think that we need to think how we can add industry specific extensions to Kanto, in a way that won't make this project a mess, because IMO if we now start to add repositories with different protocols that suits one industry or another, add meta layers for them, etc. it would be very confusing for the general community what is Kanto all about and how to use it.

Also, it would be good if you share more details about the CAN component and the standardised application interfaces that you would like to contribute, so the other Kanto contributors could share some input about them as well.

I would also want to hear how you see the structure of such extensions in the scope of Kanto, using what we now have as tools in GitHub and Eclipse.

cc @dimitar-dimitrow @hristobojilov

[carltonbale]

As I think more about the capabilities that must be addressed to achieve industry adoption, I believe one of the current gaps is CAN Datalink Abstraction and Standardization. We need a component that enables secure access to embedded controllers, across the numerous different CAN protocols that are present on a single vehicle and across industries. The problem is that these CAN protocols, such as SAEj J1939, have proprietary licenses that cannot be implemented in Open Source. Instead, proprietary commercial libraries must be employed, and these numerous commercial offerings all have different interfaces and no standardized security and access control components. This current state drives a high amount of variation and customization into the applications running on a Edge device, despite the standardizing on an OCI-based environment.

Our proposed addition to Kanto is a Datalink Abstraction and Standardization component along with complimentary CAN Datalink Access Security capabilities. This framework would be extensible across all CAN protocols as well as DOIP, allowing portability of containerized software across different hardware/provider implementations. This component would provide interface specifications for Commercial CAN Libraries to implement, as well as an SDK for implementing this agnostic interface within containerized applications. The open source component would handle the linking of these two components across an MQTT broker or other similar technology, which would be transparent for both the Commercial Library and Containerized Application.

In addition, the open source component would provide Security and Access Control for the CAN/IP datalink, including certificate-based authentication of approved applications and throttling/prioritization of traffic in order to prevent CAN datalink over-saturation.

Use cases for this functionality include being able to run the Kuksa Val data broker. This would enable creation of VSS data elements without having to customize the implementation for each specific CAN Library Implementation. The Data Broker could even be implemented without needing to specify the exact CAN protocol being used in the vehicle, enabling the Commercial CAN Library to negotiate the CAN interface.

Another use case is a Tier 1 ECU software update container, working within the Kanto Software Update Manager framework, being able to establish a secure UDS session with a powertrain ECU to perform a software update. This application would not need to be tailored for the numerous different telematics and OEM configurations. The Security and Access Control component would authenticate the Tier 1 Software Update Container, provide access to only the target CAN device, and make sure that the application does not consume too much CAN bandwidth.

cc: @k-gostev @dimitar-dimitrow @hristobojilov

[tspreck]

@carltonbale check-out how we did this mapping to VSS here: https://github.com/eclipse-sdv-blueprints/fleet-management/blob/main/spec/mapping-fms4-to-vss.md
Agreed there's still much missing considering your proposals above BUT this is a technical starting point to evaluate at least > based on COVESA discussions @SebastianSchildt @erikbosch I'd be super curious to start exploring what is missing in VSS today from this perspective

[SebastianSchildt]

My 2ct:

It certainly is a challenge that - for various reasons - the industry uses all kinds of different CAN libraries and toolings instead of just "plain linux socket can". Looking at this from KUKSA databroker perspective, this would just be different providers (i.e. imagine different "vendor-sepcific CAN-lib providers" in the picture), but that would end as @carltonbale pointed out with having to write something (completely) new for each CAN lib.

If you look at the current KUKSA provider for CAN, you will see that it is tailored to using standard socketcan interfaces. If you dig deeper into the code, you will see there is an abstract canreader class that can be implemented. This is currently sued to enable either parsing of "raw" CAN frames or alternatively J1939 formatted frames. I have also seen this used to connect proprietary CAN mechanisms, but this is "just" a nice feature of the KUKSA CAN tooling currently, while a generic "CAN Link layer" as suggested here could be used more generally.

Creating such a thing seems to me a rather hard, complex thing though. You might end up recreating one of those fancy libraries you are trying to abstract. There are also design questions: Is this only intended to provide access to Raw Can Frames (as in ID + a few bits of data), or should it be higher level, i.e. already deal with signal semantics. However, when doing that you need to deal with a lot of variance in the underlying libraries. Also is "firewalling"/traffic shaping an integrated part of this or an orthogonal aspect? This might fit better into your SDN stack.

Anyway, would such a thing magically appear, it would of course be of interest for us KUKSA guys :) Meanwhile, practically speaking, I think a lot can be achieved in short term with linux socket can, especially if raw can frame access is possible in the underlying lib. You can always use some vendor-specific API linux side to exfiltrate the frames and forward them to a Virtual socket can interface (vcan). I won't call this elegant, but certainly practical :)

[k-gostev]

My vision for the way forward:

Industry Specific Addons for Kanto

Motivation

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.

Proposal

Eclipse Kanto is a modular and flexible IoT platform, so it would be easy and natural, and technically possible to add addons that servers specific purpose.
Those addons will solve the challenges that Eclipse Kanto and its community are currently facing. Each addon will have the following characteristics:

1. Separate Eclipse Project called `Eclipse Kanto Addon for {Industry}`.
    - 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 on 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 SDV`, 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.

Conclusion

To accommodate the growing demand from the industry for domain specific components and features, we need to fully embrace the Eclipse ecosystem and build suitable addons for Eclipse Kanto, with its own governance, roadmap and experts. This will not only provide the industries with their own place to grow their solution build around Eclipse Kanto, but it will also elevate Kanto as an IoT platform.