Harden Electric Blog CANBUS Translation Device Concept Paper

CANBUS Translation Device Concept Paper

engineers in workshop


This paper delves into the concept of a CANBUS translation device, offering automotive enthusiasts the possibility of customizing their CANBUS-equipped vehicles. This possible innovation empowers individuals to embark on vehicle modifications, contingent on their access to, or ability to create, a CANBUS DBC file encompassing both sides of the car and the equipment in question. By bridging the communication gap through this translation device, users gain newfound freedom to explore and integrate diverse automotive components, revolutionizing their driving experience.

Having harboured this idea for several years, the author humbly acknowledges that the technical intricacies of this endeavour exceed their current capabilities, as they are devoted to various other pressing responsibilities. Recognizing that this ambitious concept cannot be realized in isolation, the author embraces the value of community engagement and collective ideation.

Open to the collaborative spirit of the automotive community, this concept stands as a seed for more profound discussion and contemplation. By inviting diverse perspectives, expertise, and creativity, the vision can be nurtured and elevated to new heights. It is through this collective exchange of thoughts and expertise that the concept can evolve into a truly transformative solution for automotive integration.

In essence, the author advocates for an inclusive approach that fosters open dialogue, collaboration, and shared insights. By inviting the broader community to participate in shaping the concept’s trajectory, the potential for innovation, refinement, and practical implementation amplifies significantly. Ultimately, it is this shared commitment to progress that will propel the concept towards a tangible reality, offering a cutting-edge communication system that revolutionizes the future of automotive integration.

As you read through this paper, it’s essential to bear in mind that I’m not an academic, and this paper wasn’t meant to meet all the formal academic standards. It was written over several months, so you might come across some parts that feel a bit disjointed or not perfectly polished. However, despite these potential limitations, the paper aims to offer valuable insights and ideas, and I genuinely hope they contribute meaningfully to the subject. Your understanding and consideration of these aspects would be highly appreciated as you engage with the material. Thank you for your time.

Before we continue, I want to mention that I’m an Australian, and you might notice some variations in spelling and word usage compared to American English conventions. For instance, you might come across the letter “u” in places where American English would omit it, or “s” used instead of “z” in certain contexts.

I truly appreciate your efforts in navigating these linguistic quirks, and I understand that it might be a bit perplexing for those more accustomed to American English. If it causes any inconvenience, I apologize! Language is a colourful aspect of our diverse world, and these variations are just part of the beauty of cultural diversity.

What I would like you to take away from this is the following thought:

close up view of auto mechanical gears

What if you had a computer adaptor in the same way you could have a gearbox Bellhousing Adaptor

— Christopher Scott, Founder of Harden Electric Vehicles

What is a CANDBC?

A CAN (Controller Area Network) DBC file, often simply referred to as a DBC file, is a data file format used in the field of automotive engineering and communication. CAN is a widely used protocol for enabling communication between various electronic control units (ECUs) in modern vehicles.

The acronym “DBC” stands for “Database Container File” or “Data Base for CAN” (depending on the context). DBC files are used to define and interpret the data transmitted over a CAN bus, which is a network that allows different ECUs in a vehicle to exchange information with each other.

Here’s a breakdown of what a CAN DBC file typically contains:

Message Definitions: A DBC file includes definitions of all the CAN messages used in a particular application or vehicle system. Each message typically represents a particular data set or command that an ECU wants to communicate to other ECUs on the network.

Signal Definitions: Within each message, there are multiple signals. Signals are individual pieces of data within a message and represent specific information such as temperature, speed, or engine RPM. Each signal has its own name, length, data type, scaling factor, and offset.

Node Definitions: CAN networks can have multiple nodes or ECUs connected to the bus. The DBC file lists all the nodes involved in the communication, along with their unique identifiers (Node IDs).

Signal Value Descriptions: DBC files often include descriptions for the possible values that a signal can take. For example, a signal representing the vehicle’s gear position could have values like “P” for park, “D” for drive, “R” for reverse, etc.

Comments: DBC files can have comments to provide additional information about specific messages, signals, or other aspects of the network. These comments can be helpful for understanding the purpose of different elements in the file.

DBC files are widely used in the automotive industry by engineers, software developers, and testers to understand, analyse, and develop communication protocols for ECUs in vehicles. They act as a standardized way to represent and interpret the data being exchanged over the CAN bus, which helps in efficient development and integration of various vehicle systems.

Essentially, this discussion is going to focus on the concept of using CANDBC files to create lookup tables, and then program them into a computer to allow the linking of two segregated CANBUS networks.

Why would this be required?

In contemporary automotive engineering, a prevalent characteristic of modern vehicles is the extensive integration of electronic components. Consequently, any attempt at modifying these vehicles poses significant challenges, primarily due to the intricate network of onboard computers disseminating vital information and necessitating reciprocal information exchange for proper functionality.

The increasing complexity of modern vehicles entails a sophisticated interplay of diverse sensors, wherein the correct functioning of a vehicle hinges upon seamless interactions between numerous interconnected components. A prime illustration of this interdependence is evident in the operation of an SRS (Supplemental Restraint System) Airbag device, which necessitates critical inputs from various sensors, such as the Wheel Speed Sensor on the CANBUS, to enable its activation. Similarly, certain vehicles mandate inputs from GPS devices integrated into the CAN network to ascertain their geographical location, thereby enabling the activation of specific functions, such as the charging of an electric vehicle.

Moreover, the intricate coordination among different systems becomes particularly pronounced in scenarios like the Diesel Particulate Filter Selective Catalytic Reduction Process. Here, a successful initiation of the Selective Catalytic Reduction Process requires data inputs from multiple sources, including the Wheel Speed Sensors, Engine Temperature Sensors, and Fuel Level Sensors. These inputs collectively govern the proper functioning of the catalytic reduction process, which plays a pivotal role in emissions control and compliance with environmental regulation.

In essence, the modern automotive landscape demands a comprehensive understanding and meticulous integration of a diverse array of sensors, as their cohesive cooperation forms the backbone of seamless vehicle performance and safety. The intricate web of sensor interactions underscores the significance of thorough analysis, precise calibration, and adherence to standardized communication protocols within the CAN network to ensure optimal vehicle operation and compliance with stringent regulatory requirements.

The complexity of modern vehicles demands meticulous attention when undertaking any form of modification. Given the pervasive integration of electronic systems, extending from the entertainment system and door locks to the dashboard and interior lighting, it becomes imperative to ensure seamless compatibility and functionality across the entire spectrum of traditionally “dumb” devices. A successful modification must be executed in such a manner that, from the vehicle’s perspective, no discernible changes have occurred, preserving the original harmony and coherence of the interconnected systems.

To achieve this, profound expertise in automotive engineering and a profound comprehension of the underlying communication protocols, particularly within the CAN network, are essential. Rigorous testing and validation procedures must be applied to ascertain that all the integrated systems continue to receive the requisite inputs and provide the expected responses, precisely emulating the vehicle’s unmodified state. Furthermore, adherence to industry standards and regulations is paramount to ensure not only the safety and reliability of the modified vehicle but also to comply with legal requirements and avoid potential liabilities.

Hence, any modification undertaken in the context of modern vehicles necessitates a disciplined approach, meticulous attention to detail, and an unwavering commitment to maintaining the seamless integration and optimal performance of all electronic systems. By prioritizing these considerations, automotive enthusiasts and professionals can navigate the complexities of modern vehicle modifications while upholding the integrity and functionality of the entire vehicular ecosystem.

Examples of times when this could be required.

A pertinent illustration of the importance of seamless integration and sensor compatibility arises in the context of the increasingly popular electric vehicle conversion, wherein salvaged components from electric vehicles are transplanted into different vehicle platforms. For instance, consider the scenario where components from a Tesla Model 3 are installed into a Ford Falcon Utility. In such an undertaking, not only must the existing safety systems of the Ford Falcon be meticulously retained, but equal emphasis must also be placed on ensuring that no vital sensors, previously deemed “essential” by the vehicle, are left unaccounted for despite their redundancy in the electric conversion.

Moreover, the successful integration necessitates the seamless incorporation of inputs from the Ford Falcon, including Throttle Position, Brake ABS Demands, and various other critical data streams. These inputs must be effectively parsed and conveyed to the Tesla unit, enabling it to respond intelligently and accurately to commands issued through the original equipment of the Ford Falcon.

To achieve this level of intricate coordination and compatibility, comprehensive expertise in automotive engineering, in-depth understanding of the electronic systems of both the donor and recipient vehicles, and a profound knowledge of CAN communication protocols are indispensable. Each sensor’s significance, its role in the overall vehicular ecosystem, and its influence on the proper functioning of interdependent systems must be meticulously assessed and meticulously addressed throughout the conversion process.

The significance of the integration and compatibility considerations extends beyond electric vehicle conversions and applies equally to scenarios where individuals seek to transplant specific automotive components, such as the Ford Barra motor from a Ford Falcon XR6 Turbo, into entirely different vehicles like the Chevrolet Camaro.

In such instances, a well-structured system would be essential to effectively parse engine data and the requisite inputs for the Ford Barra motor, while also ensuring the seamless exchange of data between the Ford Barra and the Chevrolet Dash and safety systems. This would allow the vehicle to feel as factory as possible.

To facilitate a streamlined and standardized process for such modifications, the development of accurate and comprehensive DBCs (Database Container Files) along with an exhaustive collection of CANBUS codes for each specific vehicle becomes imperative. An ambitious Endeavor to create a “Universal Translator” system could prove invaluable. This hypothetical system would allow users to effortlessly integrate various automotive components into their desired vehicles.

The envisioned “Universal Translator” could be designed to be user-friendly and accessible through a website or package builder. By inputting the Year, Make, and Model of their vehicle, as well as the Year, Make, and Model of the components they intend to incorporate, users could generate a pre-built package specifically tailored to their unique combination. This package would encompass the necessary DBCs, CANBUS codes, and other essential configurations, ensuring seamless compatibility and smooth communication between the disparate systems.

While the prospect of a “Universal Translator” holds great promise, it is important to acknowledge the formidable challenges in achieving comprehensive coverage of all possible vehicle combinations and configurations. The intricacies of various automotive platforms, along with the ever-evolving technologies in the automotive industry, necessitate ongoing updates and maintenance of the system to remain relevant and reliable.

Nevertheless, with careful planning, meticulous research, and a commitment to excellence, the development of such a tool could significantly ease the process of integrating automotive components from diverse sources, promoting innovation, customization, and enhanced performance for automotive enthusiasts and professionals alike.

So what does a CANBUS code look like?

A standard CANBUS message, conforming to the CAN (Controller Area Network) protocol, is a fundamental unit of communication exchanged between electronic control units (ECUs) in a vehicle or industrial automation system. Each CAN message contains specific data, and it serves as a means for different components to exchange information with one another in a distributed network.

The structure of a standard CAN message is as follows:

  1. Message Identifier (ID): The message identifier is a unique value that distinguishes one message from another. It’s typically represented by an 11-bit (CAN 2.0A) or 29-bit (CAN 2.0B) identifier, depending on the CAN version being used. Lower ID values have higher priority, meaning they take precedence over higher ID values in case of network congestion.
  2. Data Length Code (DLC): The Data Length Code specifies the number of data bytes (payload) in the message. It can range from 0 to 8 bytes. A DLC value of 0 indicates that the message contains no data (a remote frame used for requesting data).
  3. Data (Payload): The data field carries the actual information being transmitted. The number of bytes in the data field is determined by the DLC value. It can contain any relevant information, such as sensor readings, status codes, commands, or other data needed for the receiving ECUs to carry out specific functions.
  4. CRC (Cyclic Redundancy Check): The CRC field contains a checksum, which is a mathematical calculation based on the message content. It allows the receiving nodes to verify the integrity of the received message and detect any errors during transmission.
  5. Acknowledgment (ACK) Bit: After a message is transmitted, other nodes on the network will send an acknowledgment bit. If the transmitting ECU detects that no other node is transmitting at the same time, it will set the ACK bit to indicate that the message was successfully received by other ECUs on the network. If any errors occur during transmission or reception, the ACK bit will not be set, and the transmitting ECU may retry sending the message.

The standard CAN protocol is designed to be robust, reliable, and fault-tolerant. It allows for efficient communication between numerous ECUs in real-time without a central controller, making it widely used in the automotive industry and various industrial applications. The messaging structure and distributed nature of CAN contribute to its popularity as a reliable communication protocol in complex systems where multiple components need to exchange data swiftly and accurately.

Let’s consider an example of a standard CAN message for a hypothetical automotive application. For this example, we’ll create a simple CAN message representing the vehicle’s engine RPM.

  • CAN Message Identifier: 0x201
  • Data Length Code (DLC): 8 bytes
  • Data (Payload): Engine RPM value
  • CRC (Cyclic Redundancy Check): (calculated checksum)
  • ACK Bit: (to be set by receiving nodes if message is successfully received)

In this example, the CAN message has an identifier of 0x201, which is a commonly used identifier for engine-related information. The Data Length Code (DLC) is set to 8 bytes, indicating that the data field contains 8 bytes of information.

Let’s assume the payload of this message contains the engine RPM value as a 32-bit integer (4 bytes). For instance, the engine RPM value is 3000 RPM.

  • Data (Payload): 0x0B B8 00 00 (Hexadecimal representation of 3000 RPM)
  • CRC: (calculated checksum)
  • ACK Bit: (to be set by receiving nodes if message is successfully received)

The sending ECU will construct the CAN message with the identifier, DLC, payload, and CRC fields. It will then transmit this message onto the CAN bus. Other ECUs connected to the same CAN bus, such as the vehicle’s instrument cluster or transmission control module, will receive the message. If the message is received successfully and without errors, the receiving ECUs may process the engine RPM value and display it on the vehicle’s dashboard or use it for other control purposes.

This is just a simplified example of a standard CAN message. In real-world applications, CAN messages can contain more complex data and serve various purposes, such as transmitting sensor data, control commands, status information, and much more. The CAN protocol allows for a wide range of data exchange in modern vehicles and industrial systems, enabling seamless communication between different electronic components.

Let’s calculate the CRC for the message payload:

  • Data (Payload): 0x0B B8 00 00

CRC (Cyclic Redundancy Check) calculation depends on the specific algorithm used, such as CRC-16, CRC-32, etc. For this example, let’s assume a simple CRC-8 algorithm. The calculated CRC will be appended to the payload.

Assuming the CRC calculation for the payload is 0x12 (just a random example), the final CAN message in hexadecimal representation would be:

Final CAN Message:

  • 0x201 8 0B B8 00 00 12 (CAN Message Identifier, DLC, Payload, and CRC)

Note: In real-world applications, the CRC calculation and the exact message format may vary depending on the specific CAN protocol version, hardware, and software implementations. The above example is a simplified representation for illustration purposes only. In practice, automotive manufacturers and system developers use standardized message formats and robust CRC algorithms to ensure accurate and reliable data exchange on the CAN bus.

The ACK (Acknowledgment) bit in a CAN message is used to indicate whether the message was successfully received by other nodes on the CAN network. However, the presence of the ACK bit is dependent on the CAN frame type being used in the communication, and not all messages require acknowledgment.

In the CAN protocol, there are two types of frames: Data frames and Remote frames.

  • Data Frames: Data frames are the most common type of CAN messages. They carry actual data in the payload and are used for transmitting information between ECUs on the network. When a node sends a data frame, it monitors the bus to see if any other node is also transmitting a message at the same time. If no other node is transmitting, the transmitting node sets the ACK bit after completing its message transmission. Other receiving nodes, upon detecting the ACK bit being set, know that the message was successfully received by at least one other node on the bus. However, if a collision occurs (two or more nodes trying to transmit at the same time), the ACK bit will not be set, indicating an error, and the transmitting node will retry sending the message.
  • Remote Frames: Remote frames are used to request data from other nodes on the network. When a node sends a remote frame, it does not carry any data in the payload. Instead, it signals to the receiving nodes that they should send the requested data as a response. Remote frames do not require acknowledgment because they do not contain data; their purpose is to elicit data from other nodes.

In summary, the ACK bit is used in data frames to confirm successful receipt of the message by other nodes on the network. However, it is important to note that not all messages on the CAN network require acknowledgment. Remote frames, which are used for requesting data, do not carry an ACK bit since their purpose is different.

The decision to use acknowledgment or not depends on the specific application’s requirements and the type of communication strategy implemented by the system. In many cases, the robustness and fault-tolerance of the CAN protocol enable reliable data exchange even without explicit acknowledgment for every message, making it a preferred choice for automotive and industrial applications.

In certain implementations, the ACK bit has been completely deprecated, resulting in a scenario where all devices on the CAN network essentially transmit their messages without any acknowledgment of receipt by other devices. Consequently, this approach is akin to a situation where devices are “Screaming into the void” with no assurance that their communications are being acknowledged by other nodes in the network.

The motivation behind this practice is to optimize network traffic by restricting communication to only the essential data required for the vehicle’s proper functioning, thereby ensuring a “clean” and efficient data exchange environment.

However, the utilization of such a system must account for the potential coexistence of older and newer components within the same network. It necessitates acknowledgment of the differing implementations of the CANBUS ACK message, thereby accommodating the various communication paradigms that may arise.

The complexity is further compounded by an array of intricate details that could differ among diverse automotive groups, such as Volkswagen AG, Geely, General Motors, Ford, SAIC, Mercedes, Tesla, Nissan, Toyota, among many others. Even vehicles manufactured under licensing agreements or those that have been licensed from other manufacturers may introduce additional nuances to consider during integration.

A prime illustration of this multifaceted landscape is evident in the case of the Holden ZB Commodore, originally an Opel Insignia manufactured by Opel in Germany. Despite Opel’s subsequent sale by GM to PSA Group in 2017, the Holden ZB Commodore continued production and sales as a GM product. This exemplifies the intricate interplay of manufacturing affiliations, diverse implementations, and the need to harmonize disparate components within a unified CAN network.

Hence, successful integration of various automotive components demands a comprehensive understanding of the individual system intricacies, a profound grasp of differing communication protocols, and meticulous attention to detail, particularly when dealing with a diverse range of manufacturers, cross-licensed vehicles, and the varying evolution of communication standards within the automotive industry.

So what would a lookup table look like:

The process of parsing messages would necessitate the implementation of two essential tables along with a meticulously developed internal message standard for reference. To achieve comprehensive data interpretation, each conceivable type of message must be assigned a unique identifier (UID) within the internal translation system, facilitating seamless linkage across the entire framework.

As an illustration, consider the following table structure:

Table 1: Message UID Reference Table

UIDMessage NameDescription
0x01Engine RPMContains engine rotational speed data.
0x02Throttle PositionIndicates the position of the throttle pedal.
0x03Brake ABS DemandsConveys demands for the Anti-lock Braking System.

This table houses the UID, the corresponding message name, and a brief description of each specific message type. It serves as a crucial reference point for the internal translation system, enabling the seamless correlation of messages with their respective UIDs.

Table 2: Message Data Structure Table

UIDData Structure
0x01{ RPM: integer, TimeStamp: timestamp, … }
0x02{ ThrottlePosition: float, TimeStamp: timestamp, … }
0x03{ ABSDemand: boolean, TimeStamp: timestamp, … }

This second table contains the UID and the associated data structure for each message. The data structure defines the specific data fields and their respective types included in each message. The system relies on this table to accurately parse and extract the relevant information from received messages.

By establishing this standardized and well-organized approach, the internal translation system can efficiently map incoming messages to their respective UIDs, ensuring that each message’s content is accurately interpreted and utilized. Moreover, the use of UIDs enables seamless cross-referencing throughout the system, streamlining data processing and enhancing overall efficiency.

The development and adherence to such a structured message standard and parsing system are crucial for robust data handling, compatibility, and interoperability across various vehicle types and integration scenarios. Additionally, it ensures consistency and clarity in message handling, contributing to the overall reliability and effectiveness of the communication platform.

The proposed system entails a multi-stage process that operates seamlessly across the network. The following outlines each stage in a methodical and structured manner:

1. Receiving the Message on the IN BUS:

The system begins by capturing incoming messages from the IN BUS, the communication channel through which data is transmitted within the network. Messages arrive from various sources and contain specific information relevant to the vehicle’s operation and sensor readings.

2. Decoding the Message Received:

Upon reception, the system undertakes the critical task of decoding the received message. The decoding process involves extracting the data payload from the message frame, ensuring that the information is ready for further analysis and processing.

3. Referencing the Universal Table:

Next, the system consults the comprehensive Universal Table, which holds the UIDs (Unique Identifiers) and corresponding details for each message type. By referencing this table, the system establishes the message’s purpose and significance, laying the foundation for accurate data interpretation.

4. Assigning a Position on the Universal Table:

With the message’s UID identified, the system proceeds to assign it a specific position on the Universal Table. This organized arrangement enables streamlined access to message information and facilitates efficient data handling across various components.

5. Querying the Output Table for Response:

Based on the message’s UID and decoded data, the system queries the Output Table to retrieve the appropriate response data. The Output Table stores the requisite data structures and formats for generating relevant responses to be transmitted back into the network.

6. Converting the Message into the Appropriate Output Format:

Following retrieval of the appropriate response from the Output Table, the system initiates the process of converting the data into the suitable output format. This ensures that the response message adheres to the standardized communication protocol and is ready for transmission.

7. Transmitting the Message on the Output Table:

The final stage involves transmitting the formulated response message onto the Output Table, the communication channel for sending data to the target destination. The message is dispatched to the designated recipient, be it another ECU or a specific subsystem within the network, completing the data exchange cycle.

This multi-stage process is meticulously designed to ensure precise and efficient handling of messages within the system. By adhering to this systematic approach, the proposed communication platform aims to achieve seamless integration, compatibility, and reliable data exchange across diverse automotive components and vehicle types. Moreover, the modular nature of this process allows for flexibility and scalability, catering to various integration scenarios and promoting overall system resilience and adaptability.

The following is an example table of how different messages may get transmitted, as well as a brief description of why the value would have to change:

0x01RPMBB81ERecipient Vehicle multiplies the value by 10, so we have to divide the value by 10 before retransmitting
0x02ETC1A314Recipient Vehicle uses Fahrenheit, so we need to do conversions to Fahrenheit in hundreds, and recipient will convert to decimal
0x03TPS-A199C4Recipient uses more granular position, so 25% = 25.00% and 25.54% would become 2554. Ergo, multiply by 1,000
0x04TPS-B19Not used
0x05TPS-C19Not Used
0x06TPS-D19Not Used
0x08WSS-A2D1BRecipient is in Miles, Donor is in Kilometres
0x09WSS-B2B1ARecipient is in Miles, Donor is in Kilometres
0x10WSS-C2F1DRecipient is in Miles, Donor is in Kilometres
0x11WSS-D2C1BRecipient is in Miles, Donor is in Kilometres

Potential Approaches:

Approach 1: Business-Led Approach

In this business-led approach, a company would be established to oversee the research, development, and implementation of the system. The company would act as an end-to-end designer, developer, manufacturer, seller, and distributor of the system. This approach has its own set of pros and cons:


  1. Controlled Development: With a dedicated company leading the development, the process can be well-structured, organized, and managed, ensuring a systematic approach to integrating different vehicles. Comprehensive analysis and dissection of the programs and code will lead to robust and reliable integrations.
  2. Quality Assurance: The company can invest in rigorous testing and validation processes, ensuring that each integrated vehicle meets high standards of safety and performance. This would instill confidence in end-users and the automotive community.
  3. Focused Support: As the company develops and supports the system, they can provide specialized assistance and customer support, addressing specific challenges and issues faced by users during the integration process.
  4. Profit Potential: The company can monetize the system by offering it as a premium product, generating revenue from sales and aftermarket support services.


  1. Limited Accessibility: A business-led approach might lead to a proprietary system that could potentially restrict access to the source code and development tools, limiting contributions from the wider community.
  2. Slower Growth: Relying solely on a single company for development might slow down the expansion of the system as it would depend on the company’s resources and priorities.
  3. Higher Costs: Depending on the company’s pricing model, the system might come at a higher cost, limiting its accessibility to certain users or projects with constrained budgets.

Approach 2: Full Open Source Approach

In a full open-source approach, the system would be released to the community, allowing it to evolve and grow organically. The community would take up the mantle of growing, nurturing, fostering, and developing the system. This approach comes with its own set of advantages and challenges:


  1. Community Collaboration: An open-source approach encourages a diverse community of developers, enthusiasts, and experts to contribute to the project. It can harness the collective knowledge and expertise of a global community.
  2. Rapid Development: With many contributors working on various aspects, the development of the system can progress quickly, encompassing a wide range of vehicle integrations and niche cases.
  3. Adaptability: The open-source nature allows customization and adaptability to unique and unconventional integration scenarios, such as retrofitting Tesla components into older mechanical vehicles.
  4. Cost Savings: By leveraging community contributions, the cost of development can be distributed, making the system more accessible to a broader audience.


  1. Quality Control: With a diverse group of contributors, maintaining consistent quality and ensuring reliable integration across all supported vehicles might pose a challenge. Inconsistent coding standards could lead to potential issues and bugs.
  2. Fragmentation: A lack of centralized control and coordination could result in fragmentation, with various community efforts leading to different versions or forks of the system, making compatibility and support complex.
  3. Dependency on Community Interest: The success of this approach depends on the level of interest and active participation from the community. If the project doesn’t attract enough contributors, it might stagnate.

Approach 3: Hybrid Approach

In a hybrid approach, a company takes the lead in research and development while working collaboratively with the community. The company invests manpower and resources to build the base system, provide updates, and ensure stability. Meanwhile, the open-source nature allows the community to contribute, develop additional modules, and extend support for more vehicles. This approach aims to strike a balance between controlled development and community-driven growth:


  1. Comprehensive Development: The company’s involvement ensures a robust foundation for the system, prioritizing reliability and safety.
  2. Rapid Expansion: By enlisting community contributions, the system can grow faster and support a broader range of vehicles and integration scenarios.
  3. Community Engagement: The open-source aspect fosters active community involvement, encouraging collaboration and knowledge-sharing between professionals and enthusiasts.
  4. Flexibility: The hybrid model allows both the company and community to address specific needs, contributing their expertise to different aspects of the system.


  1. Complex Coordination: Balancing the efforts between the company and community can be challenging, requiring effective communication and coordination.
  2. Potential Conflicts: Differing perspectives and priorities might lead to disagreements between the company’s direction and community contributions.
  3. Fragmentation Risk: Without careful governance, the system may still face fragmentation issues if different versions emerge due to varying community contributions.

Possible development platforms:

Arduino Due

Description: The Arduino Due is a microcontroller board based on the Atmel SAM3X8E ARM Cortex-M3 CPU. It offers multiple CAN controllers and sufficient processing power for handling CAN communication tasks.

Pros of Device:

  • Dedicated CAN controllers: The Arduino Due features two built-in CAN controllers, facilitating simultaneous communication with different CAN networks.
  • Decent processing power: With its 32-bit ARM Cortex-M3 CPU running at 84 MHz, the Arduino Due can efficiently manage real-time tasks and data processing for CAN communication.
  • Arduino ecosystem: The extensive Arduino community provides a wealth of resources, libraries, and tutorials for easy integration and programming.

Cons of Device:

  • Limited memory: The Arduino Due has 96KB of SRAM, which might become a constraint for handling large datasets or complex applications.

Raspberry Pi 4

Description: The Raspberry Pi 4 is a popular single-board computer equipped with multiple USB ports, including some that can be used for CAN bus communication via external adapters.

Pros of Device:

  • Versatility: The Raspberry Pi 4 is a full-fledged computer capable of running a variety of applications alongside CAN communication tasks.
  • Large community support: The Raspberry Pi has a vast user base, offering extensive support, documentation, and software resources.
  • External CAN adapters available: The Raspberry Pi’s USB ports allow for easy connection to external CAN adapters, providing flexibility in configuring CAN communication.

Cons of Device:

  • Indirect CAN support: Unlike some Arduino boards with built-in CAN controllers, the Raspberry Pi requires external CAN adapters, which may introduce additional complexity and latency.
  • Processing load: Running multiple applications concurrently on the Raspberry Pi might impact real-time performance for time-sensitive CAN communication tasks.

Teensy 4.1

Description: The Teensy 4.1 is a powerful microcontroller board equipped with an ARM Cortex-M7 CPU, providing multiple CAN controllers and substantial processing capabilities.

Pros of Device:

  • Fast processing: The Teensy 4.1’s ARM Cortex-M7 CPU running at 600 MHz delivers high-speed data processing for demanding CAN communication applications.
  • Built-in CAN controllers: The Teensy 4.1 comes with two onboard FlexCAN controllers, allowing for direct and efficient communication with CAN networks.
  • Arduino compatibility: The Teensy platform is compatible with the Arduino IDE and libraries, making it easy to program and integrate with existing Arduino projects.

Cons of Device:

  • Smaller community compared to Arduino or Raspberry Pi: While the Teensy community is active, it may not be as extensive as the Arduino or Raspberry Pi communities, leading to potentially fewer resources and support.

BeagleBone Black

Description: The BeagleBone Black is a single-board computer with built-in CAN support and is designed for industrial applications.

Pros of Device:

  • Integrated CAN controller: The BeagleBone Black includes two onboard CAN controllers, enabling direct communication with CAN networks without the need for external adapters.
  • Robust and industrial-grade: The BeagleBone Black is designed for reliability and stability, making it suitable for industrial automation and automotive applications.
  • Ample GPIO: The board offers a substantial number of GPIO pins, facilitating connections to various sensors and actuators.

Cons of Device:

  • Learning curve: Programming and setting up the BeagleBone Black might require some initial learning, especially for users new to the platform.
  • Limited processing power compared to Raspberry Pi 4 or Teensy: The BeagleBone Black’s 1GHz ARM Cortex-A8 CPU may be less powerful for certain compute-intensive applications.

These devices offer a range of options for implementing the CAN communication system, each with its unique strengths and considerations. Selection would depend on factors such as the desired level of processing power, available memory, and the specific requirements of the application.

As the implementation of this concept is yet to be realized, the exact extent of required processing power and the suitable devices for its execution remain uncertain. While smaller scale projects have demonstrated the feasibility of operating their systems on devices akin to the Arduino Due, it should be noted that these endeavours typically exhibit simplicity and lack the comprehensive integration characteristic of OEM-level support.

Such modestly-scaled initiatives primarily focus on achieving rudimentary vehicle functionality, prioritizing minimalism in both design and support. Their fundamental purpose centres around ensuring basic vehicle operation with minimal resource utilization.

However, it is imperative to recognize that transitioning to a more encompassing and robust system necessitates careful evaluation of processing demands and compatibility with advanced functionalities characteristic of OEM-level support. Achieving seamless integration at this level requires a confluence of factors, including optimized processing capabilities, efficient data handling, and reliable communication protocols.

The presence of community-driven developments serves as a testament to the existence of viable proof-of-concept solutions within the domain. These endeavours, undertaken collaboratively by passionate enthusiasts and developers, underscore the potential of the proposed concept and its practical feasibility.

These community-driven initiatives have demonstrated successful implementations that validate the core principles of the concept. By showcasing functional prototypes and operating systems, they establish a foundation of credibility for the broader vision. These proofs of concept provide valuable insights into the intricacies of CAN communication and integration, shedding light on potential challenges and effective solutions.

The availability of these proof-of-concept implementations offers invaluable learning opportunities and serves as an inspiration for further exploration and refinement. However, it is essential to acknowledge that these initiatives often cater to specific use cases and may not fully encompass the comprehensive scale and complexity envisaged in an OEM-level support system.

As the concept continues to evolve, building upon the accomplishments of these community-driven developments can offer a solid starting point. Leveraging the knowledge gained from these successful proofs of concept can inform the iterative development process, guiding the transformation of the idea into a robust and versatile solution.

While these initial achievements provide promising glimpses into the realm of possibilities, the true potential lies in advancing beyond proof-of-concept stages and embarking on a journey of meticulous design, engineering, and integration. The ultimate realization of a comprehensive and industry-ready implementation will necessitate deliberate collaboration, robust engineering practices, and a commitment to refining the concept in alignment with real-world demands.

As the concept progresses from ideation to practical realization, diligent consideration must be given to employing devices that exhibit substantial processing power and capacity to cater to the complexities inherent in an OEM-grade support system. Ultimately, the selection of devices will significantly influence the scalability, performance, and overall efficacy of the integrated solution, underscoring the importance of making informed decisions guided by the specific requirements and scope of the envisioned application.


In conclusion, each approach has its merits and challenges. A business-led approach provides controlled development and high-quality support but might lack inclusivity.

A full open-source approach fosters rapid expansion and community engagement, but quality control and fragmentation concerns may arise.

A hybrid approach attempts to combine the best of both worlds, leveraging the strengths of a company’s development capabilities while encouraging the broader community to contribute and enhance the system.

Choosing the most suitable approach will depend on factors like project goals, available resources, community interest, and the desired level of control and accessibility.

The determination of the most appropriate approach for this endeavour is not within the purview of the author of this paper, although the author does hold personal opinions. Specifically, being a business owner, the desire for profitability naturally exists. However, the author also recognizes the vast potential and benefits that could be derived from open-source collaboration within the broader community.

In essence, adopting a rational and impartial perspective reminiscent of a “Spock-like” approach, it becomes evident that a system of this nature may indeed exemplify the principle of “Needs of the Many outweigh the needs of the Few.” Embracing an open-source scenario could prove significantly advantageous to all stakeholders involved, fostering inclusivity, innovation, and collaborative progress.

The business model, in this context, may be strategically limited to providing essential supporting hardware to complement the open-source system. Such a symbiotic arrangement could engender a harmonious ecosystem where the collective efforts of the community amplify the overall impact, benefiting a multitude of users and the broader automotive industry.

Ultimately, the decision on the most suitable approach requires careful consideration of diverse perspectives, acknowledging the potential for mutual growth and the positive influence that collaboration can exert on the larger community. Striking a balanced compromise between profit-seeking and communal benefit may pave the way for a truly transformative and forward-thinking venture.

The author of this paper acknowledges that by presenting this idea to the public, he relinquishes any exclusive control over its future trajectory. The concept is now open for the community to embrace, scrutinize, and further develop.

While the author appreciates the potential for community involvement and collaboration, he also recognizes that any attempt by another business to patent this idea would necessitate a significant departure from the fundamental context outlined in this paper. In essence, any patent-seeking entity would need to demonstrate a substantial and innovative leap beyond the foundational principles and scope covered herein.

By sharing this concept with the world, the author fosters a spirit of openness and encourages broader engagement from individuals, organizations, and the community at large. The goal is to promote collective ingenuity and catalyse advancements in the field. Simultaneously, the author seeks to safeguard against any potential attempts to claim exclusive ownership without genuinely contributing a distinct and transformative breakthrough beyond the ideas put forth in this paper.

In conclusion, the author’s intention in divulging this concept is to inspire a dynamic environment of collaboration and progress, where novel ideas can evolve and flourish collectively. While the concept is now accessible to all, the author is cognizant of the need to preserve the integrity of the original work and expects any attempts to patent it to demonstrate genuine innovation that transcends the core concepts presented here.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Post