×

Happy to Help!

This website doesn't store cookies. Enjoy the experience, without worrying about your data!

Great, thanks!

Category Archives: Case Studies

  • March 1, 2023
  • 0

UDS and CAN Stack Integration with Linux Based Telematics Control Unit

Category : Automotive , Product Engineering

 

About the Customer:

Our customer is a Europe-based Tier 1 supplier developing state-of-the-art connectivity, diagnostics and vehicle telematics solutions. Their powerful, yet flexible, solutions also enable infinite opportunities for custom application development for the automotive industry.

Business Challenge:

Our customer wanted to integrate a UDS software stack on top of CAN stack with their Telematics Control Unit (TCU) to enable vehicle diagnostics functionality. Additionally, the stack could be used for other ECU’s firmware upgrades using secured service and authentication.

The customer purchased our ready-to-deploy UDS and CAN software stacks. However, they needed assistance in integrating these stacks with the Linux OS running on their telematics system.

Our IoT engineering team partnered with the customer to integrate the software stacks on their telematics system and validate the functionalities through elaborate testing.
 

Embitel Solution:

Our UDS and CAN software stacks are hardware-agnostic. However, some customizations are needed when integrating them with various platforms based on the CAN DBC and UDS ODX configurations.

The customer shared the hardware of their telematics system with our engineering team, the required wire harness & debugging equipment. The customer has also shared a skeleton of their integration environment while safeguarding their IP rights.

  • In Linux environment, using Yocto, Embitel created a custom layer (meta layer) to incorporate all the proprietary code base and stacks. The meta layer contains libraries, applications, different GUI related applications, etc.
  • Recipe libraries were created, which contained details about our source code, its path, how to compile it and how to install it in the customer’s image.
  • Embitel cloned the meta layer and integrated it with the existing Yocto source code from the customer.
  • Embitel used proprietary tools to generate code from CAN DBC files and UDS ODX files which will reduce manual effort whenever there are changes to configuration files as per the end customer requirements.
  • Apart from software stack integration, Embitel also performed system testing and validation of all functionalities of the UDS and CAN stacks.

Ready-to-deploy UDS Stack

Embitel’s UDS stack enables diagnostics communication between the vehicle ECU and an external diagnostics device.

The stack provides a set of APIs to streamline communication between the low-level software and the application software. The communication can be over Ethernet, CAN, K-Line, etc.

The stack solution consists of the following layers:

The UDS stack is also compliant with ISO 14229 and ISO 15765 standards.

As part of this project, we implemented UDS server functionality, including security authentication of users.

Ready-to-deploy CAN Stack

In automotive solutions that are under development, implementation of our CAN stack enables ECU communication capabilities with reduced turn-around time. The stack is based on ISO 11898 standard and has a modular architecture.

Embitel’s CAN stack is ideal for supporting in-vehicle networking functionalities in passenger vehicles.

Testing:

  • PCAN tool and Busmaster tool are used to test all the CAN communications successfully.
  • The UDS stack provides multiple services. The customer had requested for 15 UDS services that they wanted to implement. Embitel has successfully integrated UDS stack for all the UDS services, added required glue code to verify specific services End-To-End, and validated the functionalities.

 

Embitel Impact:

Through the implementation of our UDS and CAN stacks, the customer was able to incorporate various features related to ECU communication and fault diagnostics.

The integration of our stack saved around 4 months of development time for the customer.
 

Tools and Technologies:

  • Linux environment
  • Yocto Build tool version Zeus (3.0)
  • CANoe for ECU testing and security access validation
  • Busmaster for CAN validation
  • Project Management tools

 

  • February 27, 2023
  • 0

Development of Air Quality Monitoring Software Module for an Automotive Tier-1

Category : In-Vehicle Networking , Product Engineering

 

About the Customer

Our customer is an automotive tier-1 and a leading player in the development of automotive solutions related to the environment and flow sensing. These solutions offer safety from poisonous pollutant gases and particulate matter found in abundance inside a vehicle cabin.

Business Challenge

Air quality monitoring system is predominantly based on sensor technology. The sensor detects harmful gases such as VOCs, hydrogen sulfide, CO etc. Integration of such sensors in an automotive HVAC system requires automotive embedded expertise and skills.

The intended air quality monitoring software presented the following challenges:

  • Time, cost, and expertise required for development of an algorithm to calculate gas-specific air quality levels and total air quality index.
  • ASPICE team was required for ASPICE L2 compliant software development.

Embitel came on-board the project to fill this gap by providing its decade long experience of developing cutting-edge automotive solutions. With proven expertise in the development of ASPICE compliant software, we were able to mitigate the business challenge faced by our customer.
 

Embitel’s Solution

As one of the early adopters of ASPICE compliance, our automotive team had a solution for every ASPICE L2 related requirement.

Once the requirements were clearly elicited, our APSICE process team and automotive embedded team joined forces to accomplish the project.

Our task was to develop an air quality monitoring module that provides:

  • Estimation for concentrations of the most relevant gases
  • Gas-specific air-quality levels and a total air quality index

Based on these values, the HVAC system in the vehicle decides the actual ventilation control to keep open or close. This software has been designed to be used across different platforms, and any changes needed will be minimal.


Software Architecture of Air Quality Monitoring Software Module

Final deliverables provided to the customer were:

  • ASPICE L2 compliant air quality monitoring software in a non-AUTOSAR based architecture
  • Low level Driver development for Armcore-M0 based ASIC chip which includes LIN Driver, I2C Driver in Master & Slave mode etc.
  • Software Layered Architecture and Modular Design
  • Hardware independent Middle layer components like HAL, COM and Service Layer
  • Reports for LIN Conformance Test against LIN Specification v2.1
  • Algorithm for Air Quality Index calculation & Heater Regulation (PI Algorithm)

 

Embitel’s Impact

We were able to reuse various components such as platform software, LIN driver etc. with minimal modification. This helped us cut cost and reduce the time-to-market.

Through our hands-on expertise in ASPICE process, our team could deliver end-to-end software development.
 

Tools and Technologies

  • Armcore-M0 based ASIC chip
  •  Code Beamer (requirements management)
  •  KeiluVision IDE
  •  CANoE
  •  Polyspace and Tessy(Unit Test)
  • January 24, 2023
  • 0

Integration of CAN and UDS Stack on Android Automotive OS

Category : In-Vehicle Networking , Product Engineering

 

About the Customer:

Our customer is a Europe-based Tier-1 supplier of automotive electronics for leading automotive OEMs. They specialize in the development of electronic equipment for passenger, industrial and commercial vehicles.

Business Challenge:

The customer has transportation devices running on Android Automotive OS 8.1. They were working on after-sales maintenance and repair of the devices. In this regard, they wanted to integrate CAN and UDS protocol stacks in their product to expedite vehicle diagnostics functionality.

The customer found that Embitel offers ready-to-deploy CAN and UDS stacks. We also have a capable IoT engineering team with experience developing infotainment system on Android Automotive.

Our automotive and IoT case studies highlighting our past projects compelled them to partner with us for this project.

Embitel Solution:

This was the first time our software stacks were being integrated on Android Automotive platform.

The customer provided us a custom board which was already running on Android 8.1 Automotive OS and also, shared their source code. Their complete work environment credentials were shared as well.

The challenge here was – We had the CAN and UDS stacks developed for MCU environment and we needed to adopt them for the Android based environment. Another challenge was to understand the customer code base and decide on the strategy to integrate the CAN and UDS stacks.

We integrated our proprietary CAN and UDS stacks with the customer’s existing software. We also performed system testing to validate all functionalities.

Here’s an overview of the steps we followed:

  1. Configured the CAN and UDS server stack code to be compatible with Android.
  2. Built the stack code as a shared library and evaluated it.
  3. Evaluated whether the expected responses are received when CAN data is sent from a simulation tool like PCAN.
  4. Tested for correct responses for all the UDS services integrated.

Ready-to-deploy UDS Stack

Embitel’s UDS stack enables diagnostics communication between the vehicle ECU and an external diagnostics device.

It offers a set of APIs to facilitate communication between the low-level software and the application software. The communication can be over CAN, Ethernet, K-Line, etc. Our stack is compliant with ISO 14229 and ISO 15765 standards.

The UDS stack has the following layers:

We assist customers in UDS protocol software integration with their hardware platform and testing.

Ready-to-deploy CAN Stack

Our CAN BUS protocol software is based on ISO 11898 standard. In automotive solutions that are under development, implementation of the stack enables ECU communication capabilities with reduced turn-around time.

The stack is ideal for supporting in-vehicle networking functionalities in passenger cars.

Our CAN stack has a modular architecture and is easy-to-integrate with various hardware systems. We have exhaustively tested the stack and test reports are shared with customers who purchase it from us.

We assist customers in the integration and configuration of CAN TP (ISO 15765) and Network Management layer. Our team also provides CAN stack testing support.
 

Embitel Impact:

The integration of the CAN and UDS stacks enabled the customer to equip their platform with various features related to ECU communication and off-board fault diagnostics. They can easily implement other desired functionalities on top of that, to enhance their diagnostic capabilities.
 

Tools and Technologies:

  • Android 8.1 Automotive OS
  • PCAN tool for validation
  • PM tool for project management
  • December 15, 2022
  • 0

Software and Hardware Development for DC-DC Converter ECU

Category : Product Engineering , Vehicle Diagnostics

About the Customer

Our customer is an automotive after-market organization delivering excellence through a wide range of automotive components. Within a few years of its inception, our customer has been able to carve a niche for itself due to its commitment to quality and disruptive innovation.
 

Business Challenge

Harnessing green energy in an efficient manner can bridge the looming energy gap, especially in the automotive industry. Our customer’s ambitious project had ‘solar energy harnessing’ at its core. In technical terms, the project aims at developing a DC-DC converter for passenger vehicles. The role of the DC-DC converter is to take in the energy from a solar panel and convert it to a voltage component that can be supplied to charge a vehicle’s battery.

The challenge that our customer was facing in realizing this project were manifold:

  • Our customer’s team was not well-versed with MATLAB and other MBD tools required to develop such an application.
  • Lack of expertise in LIN based bootloader and platform software

We got on-board the project due to our extensive experience in both software and hardware design and development using a model-based approach. On top of it, our ready-to-integrate LIN stack and pre-built platform software modules gave us an edge.
 

Embitel’s Solution

We were entrusted with end-to-end development of the DC-DC converter, i.e., software, hardware, and platform software (BSW) development.

The software and hardware teams at Embitel worked on the project simultaneously as we were on a strict deadline to finish the project.

Major highlights of the DC-DC converter ECU:

  • The ECU takes voltage and current (V,I) input from the PV (photo voltaic) cells of the solar panel and generates the required voltage (12/48 volts) for the battery to charge.
  • The ECU connects to the energy management ECU via LIN protocol to measure the voltage required by the battery for charging.
  • It is a closed loop control mechanism with a feedback loop that measures the output and instructs the DC-DC converter ECU to optimize the output voltage if it deviates from the expected value.

Here’s a snapshot of our complete DC-DC converter solution for vehicle ECU:
 

Software Application:

  • The software part comprises of a DC-DC converter ECU with closed loop control algorithm to generate the required voltage.
  • It is a configurable solution which can be modified for different vehicle and battery variants.
  • We have developed the complete platform software (BSW) for the solution.

 

Hardware Design:

  • Our hardware team has performed hardware design and simulation.
  • Board bring-up and pre-compliance test have been performed successfully.

 

Vehicle Diagnostics and Bootloader

  • We have provided vehicle diagnostics powered by UDS over LIN.
  • Flash bootloader over LIN is a part of the solution to enable ECU reprogramming.

Embitel’s Impact

We had a strict timeframe to complete the first leg of the project. Our ready-to-integrate LIN stack, pre-built platform software and expertise in MATLAB Simulink were instrumental in helping us stick to the deadline.
 

Tools and Technologies

  • Ti TMS320- Microcontroller platform
  • Code Composer- IDE and Compiler
  • CANoE – Communication
  • Matlab – Application Development
  • OrCAD- Hardware Circuit Design
  • Altium- Hardware simulation
  • November 9, 2022
  • 0

Development of End-to-End Communication Protection Module for Safety-Critical Data Transmission

Category : Others , Product Engineering

About the Customer

Our customer is an electronics manufacturing company with expertise in various control systems used in automotive and other industries.

Business Challenge

ISO 26262 compliant automotive applications involve exchange of safety-critical data amongst the ECUs. Safety-critical data must reach the intended node within the timeframe, in the correct sequence and without any loss of data.

The customer’s development team faced the challenge in implementing the required protection modules for exchange of safety-critical data. Although the customer had completed the concept phase and were ready with the technical safety-requirements (TSR) and safety-goals, implementation of some of the safety mechanism related to data transmission was posing considerable challenge.

In a nutshell,

  • End-to-end protection mechanism were to be implemented to detect and handle faults in the communication link at run-time.
  • Faults to be handled were mostly random hardware faults and systematic faults.
  • Safety-mechanisms had to meet ASIL-C requirements.

In order to mitigate this challenge, the customer was looking for a technology partner with deep domain knowledge of ECU communication as well as ISO 26262 functional safety. Embitel totally fit the bill for both ISO 26262 and ECU communication expertise.

Embitel’s Solution

End-to-End protection module was designed based on the technical safety requirements provided by the customer.

Our automotive team divided the scope of the project into two parts- E2E profile development and CRC Library implementation.

  1. E2E protection profile based on AUTOSAR 4.4 version

    2. The protection module ensured that:

    • The safety-related data exchange at runtime is protected from effects of faults within the communication. Examples of such faults are random HW faults and systematic faults.
    • By using E2E communication protection mechanisms, the faults in the communication link can be detected and handled at runtime. The E2E Library provides mechanisms for E2E protection, adequate for safety-related communication having requirements up to ASIL D.

    The E2E data exchange protection module was designed to handle the following potential faults:

    Repetition : Unintended message repetition due to the same message being unintentionally sent again.

    Loss :  message loss during transmission.

    • Insertion : insertion of messages due to receiver unintentionally receiving an additional message, which is interpreted to have correct source and destination addresses.
    • Incorrect Sequence : Re-sequencing due to the order of the data being changed during transmission, i.e., the data is not received in the same order in which it was sent.
    • Message Corruption : Message corruption due to one or more data bits in the message being changed during transmission.
    • Delay : Message delay due to the message being received correctly, but not in time.
    • Blocking : Blocking access to data bus due to a faulty node violating the expected patterns of use and demanding unwarranted service, which in turn reduces its availability to other nodes.
  2. CRC Library Implementation as per AUTOSAR 4.4 version

    3. The following cyclic redundancy check algorithms were developed and implemented to ensure the integrity of the data that is exchanged. The required version of the CRC can be chosen at runtime.

    • CRC8: SAEJ1850
    • CRC8H2F: CRC8 0x2F polynomial
    • CRC16
    • CRC32
    • CRC32P4: CRC32 0x1F4ACFB13 polynomial
    • CRC64: CRC-64-ECMA


 

Embitel’s Impact

We had assumed complete responsibility of E2E protection module development which left the customer with ample resources and bandwidth to execute development of the application parallelly.

The customer was able to integrate the E2E protection profile with the target environment without losing any time, thus reducing the turn-around time.

Since we went for AUTOSAR 4.4 implementation, all APIs were standardized, and compatibility issues were mitigated right from the start to ensure seamless integration.
 

Tools and Technologies

  • MPLAB with Embedded C
  • E2E – AUTOSAR 4.4 Specification
  • Infineon Microcontroller
  • CAPL Script
  • CANoE Environment
  • July 12, 2022
  • 0

Development of 4-Channel CAN Interface Layer Configuration Tool for an Automotive Tier-1 Supplier

Category : Modeling & Simulation , Product Engineering

About the Customer

Our customer is an Automotive Tier-1 supplier with continued focus on evolving software technologies related to battery management system, telematics and more.

Business Challenge

Automotive solutions that work on multiple CAN channels require dynamic configuration of the CAN interface layer using the CAN DBC files. While developing a similar solution, our customer’s team felt the need for a CAN IL tool with capability of simultaneous configuration of 4 CAN channels with different DBC files.

Performing this task manually would cause several issues such as:

  • Increased time to configure each CAN channel
  • Errors introduced by manual handling of CAN interface layer configuration file

Owing to these challenges, the development team of our customer decided to build an automated tool that could dynamically configure the desired CAN channels or all 4 of them in one go. The customer approached us with this challenge and as always, we were happy to help.
 

Embitel’s Solution

Developing a 4 channel CAN interface layer configuration tool was something new for us. In the past, we had developed auto configuration code generator tool, but this was different in many aspects. Our team rose to the challenge and first chose the development tool ideal for this solution which is Qt.

The development team built upon its experience of developing a single-channel tool and developed this Auto CAN IL tool. As per the requirements provided by the customer, this tool gives the option to choose the DBC file, select the CAN channel for configuration and even look into the tx and rx messages inside the DBC file.

Here’s a snapshot of the Auto CAN IL configuration tool:

CAN Interface Layer Configuration Tool

Salient Features of the Auto CAN interface layer configuration tool are:

  • 4 different DBC files can be chosen at one instance
  • Configuration files for all 4 CAN channels can be simultaneously generated
  • Network nodes inside the DBC files can be selected before the configuration
  • Schedule time, message queue size can be customized for each configuration

Along with the Auto CAN IL configuration tool, we also provided the High-level data document and unit and functional test reports and MISRA C compliance report.
 

Embitel’s Impact

The Auto CAN IL config tool single handedly reduces the configuration time by 4 times, considering only one CAN channel is configured at a given instance. On top it, the fact that 4 different DBCs can be configured solves the most difficult pain point for the customer of dynamic configuration of CAN interface layer.
 

Tools and Technologies

CAN IL configuration tool was developed using Qt, which is a cross-platform software for developing user interfaces and applications for embedded systems.

  • June 28, 2022
  • 0

Development of AUTOSAR Compliant FLS Driver Development and FLS Configuration Tool

Category : Autosar , Product Engineering

About the Customer

Our customer is an automotive tier-1 company having a diverse range of automotive solutions including emissions system, automotive interiors, connected car applications and more. We have a long-established partnership with the customer on multiple automotive projects.

Business Challenge

Resetting of the watchdog before the intended instance was the primary challenge the customer was facing. Operations like read, write, and erase etc. were taking longer than usual since the watchdog was getting reset abruptly.

Customer’s internal team deduced that this issue is trigged by the faulty FLS driver. The logical solution to the issue was to replace the FLS driver where main function of the application is separated with read/write and erase function. Since, the customer was migrating the entire system to AUTOSAR architecture, the FLS driver was also supposed to be developed according to AUTOSAR specifications.

In addition to development of an AUTOSAR based FLS driver, a tool was also required to configure the FLS driver as per the parameters.
 

Embitel’s Solution

Upon carefully going through the system architecture, Embitel’s AUTOSAR team inferred that developing the FLS driver based on AUTOSAR specifications would resolve the watchdog timer reset issue.

The gap analysis of the existing FLS driver showed us that the function to reset the watchdog timer was not being triggered in the intended manner. We used this insight to develop the FLS driver in a way that watchdog reset function is separated from the main function. Since this function constantly monitors the time elapsed in the execution of an operation, it can reset the watchdog at the intended instance and not before or after that.

The FLS driver also must be configured for usage in a specific environment. We developed a Python based configuration tool for the purpose.

Final deliverables were as follows:

  • We developed the FLS driver as per the AUTOSAR specifications provided by the customer so that all AUTOSAR compliant modules are in complete sync with each other, especially the QSPI driver which interacts directly with our FLS driver.
  • A Python-based tool was developed to configure the FSL driver as per the specifications. Since AUTOSAR code is generally static, it needs to be configured for modules like FLSS driver. Configuration items like APIs need to be enabled/disabled and parameters etc. need to be set according to configuration strategy.

FLS Configuration Tool

In addition to FLS driver and FLS configuration tool development, we also supported the customer in the integration process of FLS driver with other modules of the system.
 

Embitel’s Impact

Our FLS driver was able to resolve a major issue related to watchdog timer which was pulling down the efficiency of the entire solution. We were able to develop the tooling solution along with the driver in the provided time-frame which aided in faster turn-around time for our customer.
 

Tools and Technologies

Python: Used to build the FLS driver configuration tool

Compiler: IAR Embedded Workbench IDE
 

  • May 9, 2022
  • 0

Automated Testing and Validation of Driver Monitoring System

Category : Automation , Product Engineering

 

About the Customer

Our customer is an Australian supplier of advanced AI-driven automotive safety technology based on decades of scientific research.

Business Challenge

The customer had designed a driver monitoring system that would be installed in trucks. The system monitors the driver’s eye behaviour and facial expressions with the help of a Driver Facing Camera (DFC). It detects driver alertness, wakefulness and attentiveness and intervenes in case of any unsafe driving behaviour.

The hardware components of the driver monitoring system included:

  • In-cabin sensor – Tracks eye closure and head position to provide protection against fatigue and distraction.
  • Controller – A fan-less computer which is the heart of the driver monitoring system. All peripherals and power are connected to it.
  • Forward facing camera (Optional) – Installed in front of the vehicle to capture footages of the road
  • Vibration motors – Vibrates the seat when fatigue or distraction is detected.

The data collected by the system is also stored on the cloud.

Driver Monitoring System

The customer was seeking an experienced partner for automated testing and validation of their driver monitoring system. Since the IoT team at Embitel has worked on similar projects in the past, they decided to partner with us.
 

Embitel Solution

Automation testing and validation of the system:

  • We leveraged NI TestStand HIL System to automate the test sequences and validate the outcome. This is a customized product that takes inputs from the front camera, road facing camera, CAN bus, etc.
  • Python scripts and NI LabVIEW programs are integrated in the code for certain functions.
  • Devices involved in testing are programmable power supply, CMW for RF testing, GPS Module, NI FPGA modules, etc.

We simulated the events and analysed the system response based on the logs captured in the system.

How does the camera capture the driver’s expressions in the automation testing scenario?

We simulated the driver’s expressions manually by mimicking the gestures of a tired driver (eg. closing the eyes) in front of the driver facing camera. We also recorded various expressions in video files so that an extensive list of test cases is captured on video. These videos are used as input for the testing and validation. The NI TestStand tool takes care of the sequencing of test cases and the order in which they are executed.

What type of test cases did we execute for the driver facing camera?

The configuration file has different parameters such as blinking time, eyes closure time, etc. that helps in monitoring fatigue. Our team created the configuration file and loaded it on the driver monitoring system. The configuration file along with the recorded test case videos are provided as input for the testing. It is possible to simulate the CAN (or any other BUS) signals as well and provide that as input.

The tests are then automatically executed in sequence. When the eye closure time is more than the configured time, the system gives an alert such as a feedback vibration. Every event like fatigue, distraction, overspeed, etc. is updated in the logs. The test bench will also change the configurations to perform other tests like the negative tests.

Later, our testing team monitors the logs and validate whether the tests have passed or failed. We also validate the output to ensure that all scenarios are covered.

The logs are updated on the cloud server when the system is connected to the internet and there is good network signal reception.
 

Embitel Impact

Successful automation testing of driver monitoring system – The automated testing processes we followed reduced manual testing efforts and expedited the testing phase significantly.

Tools and Technology

  • NI TestStand HIL System
  • Python scripts and NI LabVIEW programs
  • Programmable power supply, CMW for RF testing, GPS Module, NI FPGA modules
  • May 4, 2022
  • 0

Development of SAE J2534 Pass-Thru APIs for an Automotive Tier-1: Enabling Hardware-Independent Communication

Category : In-Vehicle Networking , Product Engineering

 

About the Customer

Our customer is an Asian automotive tier-1 pioneering the development of automotive telematics and connected mobility solutions.

Business Challenge

For any ECU reprogramming, diagnostics, or telematics application to operate independent of the hardware, it needs SAE J2534 based pass-thru APIs. The automotive ecosystem is adopting this standard so that the same application can work with hardware from different vendors. Our customer had a similar requirement.

They essentially wanted the J2534 pass-thru APIs for a PC based application in .dll format. The challenge was not only to develop J2534 APIs but also to ensure that CAN messages are converted to UART before they are sent to the hardware. In addition, the integration of CAN ISO TP layer was also required. Development of ISO TP layer was in itself a skill-intensive and time-consuming task.

In a nutshell,

  • The customer wanted to collaborate with a technology provider with extensive experience in delivering SAE J2534 based solution.
  • Ready-to-integrate ISO TP layer would be a huge advantage as it would cut down the cost and reduce time-to-market for the customer.

Embitel’s Solution

Since, we had prior experience in implementing SAE J2534 for other diagnostics applications (mostly hand-held devices), we understood that a slightly different approach would be required for a PC based version.

PC based application for automotive

Architecture of our J2534 API library

Based on the requirements from our customer’s team we implemented the .dll file which comprised of the following components:

  • J2534 Wrapper API: ISO TP along with J2534 stack is written in C code. J2534 wrapper APIs are implemented to provide C++ convention for APIs and also to enable accessing the dll file in the form of an object by PC application.
  • J2534 Stack with ISO TP (ISO 15765): Communication over UDS or sending multiple message block require ISO TP layer. In this layer, we provide interface between J2534 and ISO TP so that packetization and depacketization of data is achieved at this layer itself.
  • CAN to UART interface layer: CAN data cannot be sent through COM port; hence, it needs to be serialized into UART format. There is a frame format especially defined for this. We developed this interface layer as per the conversion structure provided by the customer.
  • Windows API to COM port: These APIs are there to enable communication between USB port and the J2534 dll so that the PC application is able to open the COM port and read/write the files.
  • UART to CAN interface layer: UART frames must be converted to CAN frames, so this interface layer is implemented.

    • J2534 demo

    A Snapshot of SAE J2534 Powered PC Tool

 

Embitel’s Impact

The development time was reduced by approximately 6-8 weeks as we were able to integrate ready-to-deploy SAE J 2534 stack and ISO TP (15765) stack from our proprietary library of ECU communication and diagnostics protocol software.
 

Tools and Technologies

QT Tool: The dll was developed using QT tool

CANoe: It was used for testing the library

Test/Sample ECU: Used to test the library
 

  • March 31, 2022
  • 0

Development of a PC based CAN data base (DBC) file to .hex file Conversion Tool

Category : Product Engineering , Vehicle Diagnostics

 

About the Customer

Our customer is an automotive tier-1 supplier and an aftermarket company pioneering in the the development of cutting-edge automotive components. The company has been working on various pathbreaking automotive innovations related to all things automotive viz. automotive lighting, telematics, and more.

Business Challenge

Automotive ECUs need to be calibrated to basis their functionality. When the communication is CAN based, CAN data base (DBC) file is converted to hex file which is then downloaded as calibration for the ECU. For one of their telematics projects, our customer required a PC based tool that would achieve this conversion from CAN DBC file to .hex file dynamically.

The major challenge that the customer was facing was linked to this dynamic conversion of dbc to .hex file. Usually, DBC files are converted to .c and .h configuration files which are added to the application code. Hence, for every variant of the ECU, the configuration file has to be generated from scratch and added to the code. Through this project, the customer aimed to make this process dynamic by a PC based tool for dbc to .hex file generation that would configure the calibration memory of the bootloader.

Embitel’s Solution

Our automotive team has delivered several projects related to the development of PC based tools. However, the conversion of CAN dbc files to .hex files was an interesting outing for them. The team chose QT as the platform to develop this PC based DBC to .hex file conversion tool.

As per the requirement of the project, there were two CAN channels and two DBCs to be configured. The tool, however, is designed in a way that it is independent of the internal network architecture and number of DBC files. It can cater to any number of calibrations, DBCs and network channels. All you need to do is to choose the desired DBC file and specify the memory location of the calibration where the .hex file needs to be uploaded.

DBC to hex converter tool
A snapshot of the CAN DBC to .hex file tool

The tool is designed to carry out this task by:

  • Downloading the DBC file provided by the OEM and displaying all network nodes of the DBC file
  • The Tx and Rx messages contained inside the DBC are
  • DBC to hex file conversion is carried out by first feeding in the Hex file start address.
  • hex file is generated and uploaded to the calibration memory of the flash bootloader.

We also provided the CAN flashing tool using which the .hex configuration file could be uploaded to the desired calibration memory.
 

Embitel’s Impact

For the fact that this tool is scalable and independent of network architecture of the ECU, it can be used to manage any number of vehicle variant with multiple calibrations. This was a big plus for the customer as this tool was future ready.

By automating the generation of hex file, the customer will be able to save a considerable amount of time and get a reliable hex file that can be readily integrated to the flash bootloader calibration memory.

Our execution of this project resulted in saving substantial resources both in terms of monetary and human resources.
 

Tools and Technologies

QT tool was used to develop this PC based .dbc to hex file conversion tool.

« Previous Page — Next Page »

Archives

Contact Us

© 2018 Embitel. All Rights Reserved