CAN FD Stack Integration Services
Need for CAN FD – a next generation vehicle network protocol
The modern vehicle manufacturers stipulate transmission of larger amounts of data at optimum rates across the vehicle network. And The Classical CAN BUS protocol supports the transfer of only up to 8 bytes of data.
Hence, there was a need for next generation CAN protocol. CAN FD (CAN with flexible data rate) vehicle network protocol has been designed to support up to 64 bytes of data transfer
CAN FD stack Integration, Configuration, and Testing services:
The CAN FD drivers or firmware, an interface layer and a network management layer have been designed, developed and tested according to ISO 11898 standard.
End-user Application Analysis:Detailed analysis of the user application/vehicle application layer to understand the extent of customizations needed for the CAN Network layer
CAN FD Stack Integration Services:Integration and configuration of the CAN software stack with three software layer services. The software stack solution comprises of CAN FD drivers, Interface layer, and Network Management layer.
CAN FD Bootloader Services:The CAN FD Bootloader development to support re-programming of the automotive ECU.Testing services for the CAN FD Bootloader as per the ISO standards.
Conformance Testing Services:Testing and validation of the pre-defined test cases as per the ISO 16845 standards.Integration testing of the end-user application.
CAN FD stack Factsheet:
This downloadable Fact sheet contains all the details of our pre-tested and stable CAN FD stack mainly used for ECU reprogramming and diagnostics:
Download this CAN FD PDF to get following information:
- CAN FD license fee, engagement model, and overview
- Benefits of IP rights and CAN FD source code
- CAN FD solution package, features, memory requirements
- CAN FD stack integration and maintenance support services
Refer to the CAN FD Stack FAQ sections for more details.
FAQs about CAN FD Stack Integration
Q. Which software modules are included in your ready-to-deploy CAN-FD stack?
Ans. Our pre-tested CAN-FD stack solution consists of the following software services. The low level device drivers are platform dependent
- CAN-FD Device Drivers
- CAN-FD Network management layer
- CAN-FD Interface Layer
Q. Do you also provide stack integration support services in addition to the software stack solution?
Ans. Yes we provide complete analysis, stack integration and maintenance support services as part of our Service Level Agreement (SLA).
Q. Do you provide ECU reprogramming solution/bootloader development as a part of the CAN FD software stack?
Ans. We provide consultation to our customers for existing sequence of the CAN FD bootloader module.
However, we can also collaborate for development of the CAN FD bootloader solution based on the proposed bootloader design as per the project requirements.
Q. Is the CAN FD software stack complaint to any specific standard?
Ans. Our CAN FD software stack is compliant to ISO11898 standard.
Q. Does the CAN FD software code development adhere to any coding guidelines?
Ans. The software source code is developed using embedded C in compliance with MISRA-C standard.
We adhere to software development best practices as per CMMI level 3 standards at the organization level.
Q. Is it possible to configure Tx and Rx messages for the CAN FD Interface layer module?
Ans. In the CAN FD software stack, the CAN FD Interface layer can be customized as per your project/application requirement.
Static configuration is provided for customizing Tx and Rx messages through Cfg.c and Cfg.h files.
Q. Is your CAN FD stack proven for compatibility with a production environment?
Ans. As a technology partner, we have partnered with global OEMs’ and suppliers for integration of CAN FD stack. Our CAN FD stack has been Tested OK during several end-of-line testing and has been integrated with the production environments.
Specific success stories of our customers can be shared (on request) after signing the NDA.
Q. Do you provide conformance testing services for CAN FD software stack as per ISO standard?
Ans. We have a team of expert automotive software engineers who have experience in delivering optimal solution for integration testing and compliance testing as per ISO 16845 standard.
Q. Please provide details of your licensing policies?
Ans. According to our existing business model we provide one-time licensing to our customer.
This includes IP rights and source code of the CAN FD software stack. This model benefits the customer, as it lends flexibility of integrating the software stack across multiple projects or product lines.
Nevertheless, our business model can be re-planned according to the customer needs.
Classical CAN v/s CAN FD frame architecture
Following diagram is the graphical comparison between the frame architecture of Classical CAN and CAN FD protocol
Source: CAN CIA Organisation
What are the advantages of CAN FD over CAN?
CAN FD protocol supports increased bandwidth for data communication across the automotive ECUs within a vehicle network.The following are some of the benefits of using CAN FD protocol over the legacy CAN-BUS protocol.
- Improved Data Rate: The Classical CAN protocol allows the bandwidth of 1 Mbit/s whereas CAN FD protocol supports bandwidth more than 8 Mbit/s.
- Support for larger payloads ( data):
- CAN FD supports up to 64 bytes of data field as compared to Classical CAN that supports up to 8 bytes of data
- Due to high bandwidth capacity and larger payload (data field), CAN FD stack doesn’t require transport layer protocol for enabling the in-vehicle network communication among ECUs
- During ECU re-programming, the speed of data transmission (data of sizes larger than 8 bytes) is significantly higher in a CAN FD network as compared to classical CAN.
- Thus the end-of-line software upgrade can be done more efficiently, that translates into time and cost savings
- Improve Real-time data transfer
During in-vehicle ECU communications, a single message (or data signal) is transferred as multiple independent packets.
Since CAN FD supports 8 times more data volume than Classical CAN, the transfer rates are faster and signal fidelity is better due to simpler packet management
All these factors play a significant role while developing real-time data transfer applications
- Data security
The data security parameter in CAN FD remains the same as that of the classical CAN despite the increased data packet size.
This is achieved by using longer CRC check keys with adapted algorithms.
- Backward compatibility
The CAN FD controllers can be used as classical CAN nodes as well. Hence the legacy network nodes can be gradually replaced with CAN FD-capable devices.
When the entire network becomes CAN FD complaint, then the advantages of this next generation CAN are realized to the fullest extent
The architecture of CAN FD software stack
We have designed and developed a CAN FD software stack which is similar to CAN bus. The CAN FD stack can be integrated with your applications to help reduce time-to-market for the product development.
Our pre-packaged and off the shelf stack is effective in saving the development time and helps the OEMs to focus on product development.
The software layers of the CAN FD stack support following functionalities:
- CAN FD Driver: This layer is created to enable the physical layer interaction with the higher layers of the stack. It helps in the abstraction of the transmitting and receiving of data from the ECU hardware
- CAN FD Interface Layer: This layer helps in the routing of the Bus channel regardless of its location. CAN FD Interface help in the abstraction of the driver from the higher layers because the higher application layers only interact with the channels and not the ECUs
CAN FD interface layer also ensure hardware independence thus ensuring reusability of this stack across platforms
- CAN FD Network Layer: The network BUS transitions between various modes of operation cycles namely bus-off or sleep mode, active and inactive mode.
Network management layer sends a notification to the application layer about the status of the CAN BUS to the vehicle application layer.
The Tx and Rx messages between the NM layer and the user application are configured to achieve the same.