×

Happy to Help!

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

Great, thanks!

Category Archives: Automotive

  • 0

Integration of CAN and UDS Stack on Android Automotive OS

 

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

  • 0

Software and Hardware Development for DC-DC Converter ECU

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

  • 0

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

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.
  3. CRC Library Implementation as per AUTOSAR 4.4 version
  4. 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

  • 0

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

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.


  • 0

Development of AUTOSAR Compliant FLS Driver Development and FLS Configuration Tool

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
 


  • 0

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

 

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
 


  • 0

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

 

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.


  • 0

Development and Testing of Electronic Steering Column Adjustment System for an Automotive Tier-1

About the Customer

We partnered with an automotive Tier-1 supplier with a vision to develop future-ready automotive solutions. Our collaboration with this company spans multiple projects related to solution development, ISO 26262 compliance, verification and validation support, flash bootloader development and more.

Business Challenge

Our customer was developing an electronic steering adjustment system (Tilt and telescopic). Since the project follows ASPICE standard, development and complete testing of the system also needs to be performed as per ASPICE. Unit Testing, Integration Testing, and Functional testing (System testing) of such a complex solution requires enormous amount of man hours, if performed manually.

Key challenges:

  • Expertise required for tools like VT system for HIL testing
  • ASPICE system level 2 expertise was required
  • Expertise in tools for Unit testing, integration testing and static code analysis

To mitigate these challenges and complete the testing as per ASPICE standard, the customer came on-board with us.

Embitel’s Solution

Phase-wise release of the solution was planned during the discussions with the customer and our development team.

Following aspects were part of the project plan:

  • Software design, implementation, and testing
  • Hardware design, implementation, and testing
  • System design and testing (HIL testing using VT system)
  • ASPICE compliance by maintaining bi-direction traceability, so that every point in the report traces back to a requirement

Entire spectrum of testing right from unit testing and integration testing to software qualification testing was covered during the project lifecycle. The testing team was built in a way to include experts of all forms of testing.

Final Deliverables of the Testing Activities:

  • Summary test report
  • Release report
  • Separate document listing issues raised during testing
  • Diagnostics and fault testing document (open current, overload current)

We followed the ASPICE v3.1 standard document for planning and executing the test activities.

ASPICE v3.1 standard
 

Embitel’s Impact

We automated the functional testing of ECU which resulted in 70-80% of code being tested in the automation mode. Using CAPL scripting, the test cases were automated and the execution of tests took only 4-5 hours. It would have otherwise taken 1-2 weeks for manual testing.
 

Tools and Technologies

DOORS tool: DOORS is a requirement management tool. It is used to create test cases based on the requirements.

V Test Studio: V Test Studio is a test authoring tool for embedded systems.

CANoe: It is a software tool for development, test and analysis of automotive ECUs.

CAPL: CAPL scripting is used to automate test case creation and execution.


  • 0

Hardware Development for Electric Motorcycle Dashboard

 

About the Customer

Our customer is a US-based electric motorcycle manufacturer developing high-end connected two-wheelers. The revolutionary designs and technology in their motorcycles are enhanced by the company’s promise of sustainability through the utilisation of high-performance, recyclable materials.

Business Challenge

The customer was seeking a reliable automotive product development company for the design and development of the hardware that powers their electric motorcycle dashboard. They partnered with us since we have worked on multiple automotive projects in the past, where we designed and developed the end-to-end hardware system.

The customer’s motorcycle product line was equipped with leading-edge technology and connectivity options. For instance, the driver can receive crucial vehicle data on his/her mobile phone app, as smart connectivity has been implemented in the vehicle.

Our scope of work in this project was limited to the hardware solution implementation and performance evaluation. The development of the dashboard software and mobile application was done by the client themselves.
 

Embitel Solution

We designed and developed a hardware carrier board and a secondary board for the motorcycle dashboard. These boards were interconnected and the communication with mobile, GPS, CAN transmission, 4G, etc. were established.

The project consisted of 2 spins. In each spin, the following activities were performed:

  • Selection of components and hardware design with Schematics
  • Board layout and Gerber generation
  • Proto board manufacturing
  • Board bring up
  • Validation of electrical design
  • Integration of the software and elaborate testing

At the end of spin 2, we also provided support to the customer for Pre-compliance and Field testing.

Architecture diagram

Toradex Ixora Carrier Board Interfaces:

Toradex Ixora

Source – Toradex

Bike Interface Unit – High Level Block Diagram:

thumbnail_image0012-01

 

Key modules of our solution

Toradex IMX 6 series SOM processor was used for the carrier board. The secondary board does not have a processor, as it is an add-on board with limited features. The complete circuit is entirely on the main board (carrier board).

The carrier board is placed at the top of the stack for optimum heat dissipation. It connects with the secondary board using automotive grade fasteners. The SOM module takes care of interfaces such as Memory, GPIO, CAN, I2C and USB bus, HDMI, Ethernet, RS232, etc.

Some of the components included on the carrier board:

  • System on Module Apalis iMX6
  • Bluetooth and Wi-Fi Combo Module
  • RS232 Transceiver
  • CAN Transceiver
  • LTE Module
  • Ethernet
  • CAN Controller

Some of the components included on the secondary board:

  • I2C to GPIO Expander
  • I2C to ADC Expander
  • Relays
  • Temperature and Humidity Sensor
  • Current Limit Switch

An elaborate power management module was also included in the solution.

Performance evaluation

Performance evaluation of the solution was done after the software was integrated with the hardware. Performance testing was carried out with the maximum limits of boundary values.

Simulations were also carried out for all the applicable circuits and the simulated results were cross verified with the test results.

Security considerations

While selecting the hardware components, we took care of incorporating the security aspects. We have only opted for automotive grade components for the boards.
 

Embitel Impact

The hardware boards we developed for the motorcycle digital instrument cluster were in conformance to the client’s requirements. The performance of the system was evaluated, and we supported the customer in all pre-compliance and field tests. The customer is now in the process of manufacturing hundreds of these boards for their high-end motorcycle product line.

Tools and Technology

  • Cadence Orcad v 17.4 – For hardware design
  • PM Tool – For task management, effort logging, etc.

  • 0

Implementation of SAE J1939 based Secure Bootloader for an Automotive Tier-1 Supplier

About the Customer

Our customer is a tier-1 supplier of automotive components with deep focus on developing the solutions for future mobility. Our automotive teams have been involved in multiple projects with the customer across various technologies and implementations.

Business Challenge

Flash bootloader is an integral part of an automotive software. Since bootloaders are specific to the underlying communication protocol, they need to be developed based on specific project’s requirements. In one of its new programs, the customer required a SAE J1939 based bootloader with security features. A configuration tool was also required to configure the vehicle application layer (SAE J1939-71) of J1939 protocol software.

Major challenges faced by the customer were related to:

  • Availability of ready-to-deploy SAE J1939 protocol and expertise related to configuration of PGNs and SPNs for J1939 protocol software
  • Right technology partner for PC based tool development for ECU reprogramming
  • Lack of expertise in development of secure bootloader, specifically J1939-based bootloader

 

Embitel’s Solution

We have readily available SAE J1939 protocol software that can be configured as per the requirements and types of messages to be sent. On top of that, our expertise in implementation of various cybersecurity features in flash bootloader has been quite extensive. Both these attributes made us the choice technology partner for this project.

After a series of discussions among the teams, we were able to prepare a detailed flow diagram indicating the message flow through various layers and interfaces used in each layer.

Implementation of SAE J1939

A snapshot of the tasks performed by the project team:

  1. We deployed our ready-to-deploy SAE J1939 protocol stack and configured it based on requirements provided by the customer. One of the major customizations that we performed was ‘read and write’ of SPN values to be executed in nano seconds, compared to micro seconds in general implementations.
  2. Sequence of Bootloader was customized based on customer needs.
  3. We developed a tool based on CAPL scripting for reprograming of ECU.

The final deliverables included the following:

  • J1939 stack and corresponding artifacts like LLD, MTD etc.
  • Bootloader and sample application
  • Reprogramming tool based on CAPL
  • Validation test plan and report

Embitel’s Impact

The development time of the project was reduced by at least 6 months since we deployed our proven SAE J1939 protocol software. As a result, our customer was able to reduce the time-to-market and the overall cost of the project.

Additionally, our extensive experience in development and implementation of secure bootloader enabled us to deliver a robust and cutting-edge bootloader solution.

Tools and Technologies

  • MPLAB X IDE: It is an IDE from Microchip that helps develop, debug, and qualify embedded software
  • CANOE: CANOE from Vector was used to test and analyse ECU network
  • CAPL: PC based tool for ECU reprogramming was developed using Vector’s CAPL (Communication Access Programming Language)