×

Happy to Help!

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

Great, thanks!

How to Integrate J1939 Software Stack With an Automotive ECU: A Step-by-Step Tutorial

  • 0

How to Integrate J1939 Software Stack With an Automotive ECU: A Step-by-Step Tutorial

If you are an embedded software engineer (or an enthusiast) ready to kick start your career in the exciting automotive ECU development space; this tutorial can serve as a high-level hands-on of J1939 stack integration with automotive ECU and/or tooling applications

Why J1939 stack integration in automotive ECU applications:

Before we start with our J1939 tutorial and address the step-by-step process involved behind the J1939 software stack integration, let us first look at the significance of J1939 integration.

  • J1939 software stack is compliant with SAE J1939 standard.
  • This software standard, defined by Society of Automotive Engineers (SAE), has been designed to ensure that Electronic Control Units (ECU) (manufactured by different automotive suppliers) follow a standard format to communicate with each other.
  • This standardization ensures interoperability between control units from different suppliers along with other benefits
  • J1939 software stack, in particular, supports communication and diagnostics services over CAN bus for commercial vehicle applications

 

Decoding J1939 software stack integration process:

In the system architecture diagram shown below, we observe that:

  • The J1939 stack is the middleware (middle layer) software
  • J1939 software stack is integrated between the Low Level Device Drivers (LLDs’) and automotive application.
  • In addition to this, there is also a J1939 based Bootloader software (part of the J1939 stack) and a Scheduler software, that are part of the ECU software architecture

J1939 based Bootloader software
 

Following are the steps involved in J1939 software stack integration:

Step 1: Development of APIs’ (and device drivers) for integration with target platform and application layer:

  • The Low-Level Device Driver layer consists of all the device driver software code that facilitate access to the underlying hardware platform (MCU, I/O ports, Timer) and other integrated peripherals
  • To enable communication of this Low-Level Device Driver layer with the Middleware Software (aka J1939 stack), an API software is designed
  • Such an API is designed to leverage following advantages:
    • The customer (an Automotive OEM/Supplier/Tooling vendor) may choose to provide only limited or no access of the low-level device drivers to the third party J1939 stack vendor. (Reason: This helps to safe-guard the mission critical data and architecture.)
    • In such scenarios, the software services vendor develops this API (as part of the J1939 package) which can be integrated with the low-level layer by the customer’s in-house software development team.

    • Since low-level device driver programming is more complicated, the higher level interface, facilitated by an API, makes configuration, customization and/or modification much simpler for the software developers
  • An API is also designed to enable integration with the target application layer of the ECU/Tooling system

 

Step 2: Configuration of the Middleware layer (J1939 stack)

  • There are several off-the-shelf J1939 software solutions available in the market.
  • Automotive companies, over the years, have shown confidence in such pre-tested stack solutions. Such ready-to-deploy J1939 stacks add value by saving development time and cost
  • However, to integrate this stack solution, the vendor provides support for the configuration of Application (J1939 – 71) and Diagnostics (J1939 – 73) layers
  • The level of configuration and customization required, depends on the business needs of the end-user application
  • Configuration of J1939/71 Layer: This layer is configured to define Parameter Group Numbers (PGNs), Suspect Parameter Numbers (SPNs) with the Scaling, Limits and Parameter Offset Size.
  • Configuration of J1939/73 Layer: This layer is configured to define Diagnostic Trouble Codes (DTC), Diagnostic Parameter Group Definitions and Diagnostic Messages (DM)

 

Pro-tip: This blog tells you how to test the quality of J1939 source code before integrating it with your ECU application.
 

Step 3: Compilation and Porting of the code on Target Hardware Platform

The general steps for compilation of source code into an executable file, are as follows:

  • Pre-processing: In this step the source code file is processed and transformed for compilation.
  • For an instance, if the code is written in C or C++ then the source code file will be in .c or .cpp format. The output of the pre-processing stage is .i or .ii file format.

  • Compilation: The output of the compilation stage is a file containing assembly language code to be interpreted by the assembler.
  • Assemble: In this stage the input file of assembly language code is converted into machine language file.
  • Linking: The linking phase of compilation process is responsible for producing an executable file.

To summarise, using an Integrated Development Environment (IDE),the source code is converted into an executable format. The compiled output files which are in .hex and .s19 format can be ported directly on the target Hardware platform.
 
Other optional steps involved for the integration of J1939 software stack:

  • J1939 Bootloader software development:
  • The Bootloader software is required for re-programming of the Automotive ECU. The bootloader functionality is a part of the J1939 software stack.

    Depending on the automotive application requirements, the J1939 bootloader sequence can be configured.

    Also, the bootloader logic is implemented separately for both boot and application areas.

  • Scheduler software development for non-RTOS systems:
  • In simple terms, a scheduler helps the embedded system to multitask in an organized way.

    Scheduling of tasks is imperative, due to increasing complexity of functionality in the layered system architecture.

    The scheduler software can be configured in two ways:

    • Based on the required time constraints set upon each tasks
    • Based on the number of tasks that have to be configured within a particular timestamp.

 

Challenges you may face during integration of J1939 Software Stack:

As you may have realized, integration of J1939 stack involves ensuring compatibility between three layers: Low-Level Device Drivers, J1939 stack layer and the Application Layer

The challenges during such a J1939 integration project are encountered due to faults at or limited access to the device drivers layer and/or application layer of the customer devices

If your J1939 stack source code is robust, pre-tested and has been proven by integrations across different platforms for different projects, then it is unlikely that you will face challenges due to faults or errors in the middleware software layer

Following are some suggestions to resolve a road-block during a J1939 software integration project:

  • When a specific software module in the LLD is faulty:
  • Fault may occur during J1939 software stack integration with the LLD layer, due to reason such as improper functioning of CAN module.

    In such a scenario, the error can be handled by carrying out the RCA (Root cause analysis).

    In cases where the customer shares limited access or no access to the LLD layer, the concerned teams from both the customer and vendor’s organization need to collaborate to resolve the issue.

  • When the application layer sequence is faulty:
  • The end user application can create a hurdle if it does not function properly.

    For example,if a data identifier does not have a proper sequence or format then, the particular diagnostic instruction will not be interpreted accurately by the ECU.

    If the application is developed by the customer, it is recommended to share the legacy library with the team responsible for integration of J1939 stack.

    This legacy library has details of the interface requirement of the application. This knowledge can help a software development team to resolve critical issues.

For more details or queries regarding integration of J1939 solution, please get in touch with our experienced team of automotive software developers


  • -

Library of Vehicle Diagnostics and Communication Software Stacks

 

Transformation of Engine Control Unit (ECU) into Electronic Control Unit (ECU)

The Electronic/Electrical (E/E) systems within automotive now have more than 10 million lines of software code!

As an embedded technology partner for our global automotive customers, we have witnessed this transformation over the past 10 years

For such complex E/E systems robust network communications and diagnostic software protocols are critical for tracking and controlling of vehicle parameters.

.

Library of ECU communication and diagnostics stacks

In compliance with Automotive and International Standards (SAE and ISO), we have designed and developed a suite of pre-tested and pre-packaged vehicle network communication and diagnostics protocols

All the stacks can be readily integrated with any Automotive ECU and tooling applications

 

Automotive Strack Library

 

J1939 stack

J1939 Stack
The SAE J1939 complaint software stack and boot loader has ensured reduction in software development costs and time for our global customers.

Following are some success stories of J1939 stack integration

  • Android based Infotainment platform – J1939 stack helps the IVI platform to fetch vehicle parameters and diagnostics information. The stack is integrated with Linux/Android operating system, and around 50 PGNs are configured.

Read the complete success story here

  • Electronic Power Steering (EPS) system – The complete stack is integrated with EPS system for supporting vehicle communication, reprogramming, diagnostics and fault code memory.

Read the complete success story here

Learn more about the J1939 stack integration services

J1939 software stack Factsheet:

J1939 Stack PDF

Our J1939 solution for commercial and light passenger vehicles has been deployed in several production programs, across the US, Europe and India.

Download this J1939 Factsheet PDF to know more about this solution

What this factsheet offers:

  • Details about J1939 licensing model and business engagement model
  • How our customers benefit by owning J1939 IP rights and access to J1939 source code
  • What are the J1939 software features, OS compatibility, memory requirements
  • J1939 stack integration, testing and maintenance services (pre and post production) offered by our Automotive Software Development team, based out of Bangalore, India

 

UDS Stack

UDS module, designed as per ISO 14229 standard, implements diagnostic services which allow a diagnostic tester (client) to control functions in an ECU (server).

UDS implementation is independent of physical layer and it is compatible over both LIN and CAN implementation

Embitel has ready-to-integrate solutions to support UDS based diagnostic implementation for control units and boot loaders based on UDS and tooling solutions for end of line reprogramming, service station diagnostics and remote diagnostics

Following are some success stories of UDS stack integration

  • Diagnostics and reprogramming stack for body control unit
  • UDS over LIN diagnostics stack and reprogramming for roof control systems
  • Cloud based remote diagnostics
  • UDS based diagnostic tester – Customer Success Story

 KWP2000 Stack

KWP2000 stack, designed as per ISO 14230 standard, implements diagnostic services that allow a diagnostic tester (client) to control functions in an automotive ECU (server).

Our Automotive team has designed software stacks for KWP2000 over K-Line and KWP2000 over CAN (based on ISO 15765)

We have ready-to-deploy solutions to support KWP2000 based diagnostic implementation for control units and bootloaders (over K-Line and CAN)

Following are some success stories of KWP2000 stack integration

  • Diagnostics and reprogramming stack for Engine Control Unit (ECU)
  • End of line reprogramming over K-Line

OBD/OBD II Stack

Designed and developed in compliance with ISO-15031, the OBD II stack is independent of platform and application.

It is portable to several Microcontroller families (8, 16 and 32 Bit Microcontrollers)

Learn more about our OBD II stack integration services

We support OBD stack on the following Network Protocols:

  • OBD over CAN (ISO15765)
  • OBD Over Kline ( Using KWP2000 Protocol)
  • OBD Over J1850 ( PWM and VPW)
  • OBD over ISO 9141-2

OBD Stack

Following are some success stories of OBD stack integration

  • OBD II stack and Fault Code Memory implementation for Engine control unit – customer success story
  • OBD II solutions for after-market automotive products. Support for accessing vehicle parameters through OBD port – supports CAN, K-Line, J1850 physical interfaces

 

OBD2 software stack Factsheet:

OBD-PDF-Image

This OBD2 software stack handbook serves as a quick guide to understand our ready-to-deploy OBD2 solution for diagnostic and emissions control applications in passenger vehicles.

Download this OBD2 factsheet PDF to get following information:

  • Deployment of OBD2 solution in Automotive ECU, Tooling and Telematics Applications
  • OBD2 licensing model, our business engagement model, and OBD2 stack package overview
  • OBD2 Features, platform details, OS compatibility and memory requirements
  • OBD2 software stack development, testing, support and maintenance services provided by our Automotive Product Engineering Services team

 

ISOBus / ISO 11783 stack

ISOBus/ ISO 11783 stack is an extension of J1939 stack. This is designed to meet the needs of agricultural and off-road vehicle market.

Our embedded developers have developed this stack to ensure easy integration with agriculture and off-road vehicle applications

Following are some success stories of ISOBus stack integration

  • Design and development of ISOBus stack for agriculture tractor-based application
.

ISOBUS software stack Factsheet:

ISOBUS PDF

Our Automotive Embedded Software developers have designed this ISOBUS software solution is in compliance with ISO 11783 standard (defined for agricultural and forestry based tractors & implement applications)

Download this ISOBUS software stack PDF to get all the details about this pre-tested and proven solution

This ISOBUS factsheet/handbook contains the following information:

  • ISOBUS licensing fee, our business model, and ISOBUS software stack overview
  • Benefits of our unique offering – customer gets the owenership of ISOBUS IP rights and source code
  • ISOBUS solution package, features, memory requirements, configuration & customization
  • ISOBUS software stack Integration, testing, maintenance, support services

 

J1587 stack over J1708 physical layer

J1587 stack over J1708 physical layer is used in commercial vehicles for vehicle communication and diagnostics services.

Our embedded automotive developers have designed complete J1587 stack and is readily available for integration with customer’s application

Following are some success stories of J1587 stack implementation

  • J1587 stack solution for after-market automotive product. This solution was designed over J1708 physical layer to support access to the vehicle parameters
.

Calibration protocols

We have experience in integrating CCP and XCP protocols for automotive ECU calibrations. These protocols are integrated to ECUs like body control modules to facilitate calibration

Following are some success stories of calibration protocol integration

  • CCP integration with Engine Control Unit
  • XCP over LIN integration with roof control system
.

Boot loaders

Our developers have in-depth expertise and experience in providing solutions for end of line reprogramming – this include design and development of boot loaders for electronic control units (ECU) and tooling applications to facilitate reprogramming

We have boot loader solutions compatible with the following automotive protocols

  • J1939 (over CAN)
  • UDS (over CAN, LIN)
  • KWP2000 (over CAN, K-Line)
  • Custom (over Bluetooth, SPI, Serial/UART)

Flash Bootloader Factsheet:

Flash Bootloader-PDF-Image

Our Flash Bootloader software is a time-tested solution. It has been deployed ( in more than 5 years) in automotive production programs across US, India and Europe.

This is a stable and ready-to-deploy flash bootloader solution compatible with application-level protocols like UDS, J1939 and KWP2000.

Download this Flash Bootloader PDF to get following information:

  • What you get with the Bootloader Solution Kit: Script & Tools development, Primary and Secondary bootloader
  • Know about all the Bootloader solution features and memory requirements
  • Compatibility with different vehicle communication protocols

 


  • 0

What is J1939 software stack?

Learn about the layered architecture and diagnostic trouble codes (DTC)

What is SAE J1939 – an introduction?

SAE J1939 is a software standard defined by Society of Automotive Engineers (SAE). This software standard has been designed to ensure that Electronic Control Units (ECU) manufactured by different automotive suppliers are able to communicate with each other within an in-vehicle network.

SAE J1939 standard is defined for applications in commercial vehicles for CAN (Controller Area Network) bus.

What is J1939 stack?

J1939 stack is an embedded software stack with layered architecture, compliant with SAE J1939 standard.

This pre-tested software stack, designed by our embedded automotive engineers, can be easily integrated with commercial vehicle applications for diagnostics and communication services.

Our product engineering team has also developed J1939 bootloader for automotive ECU reprogramming services.

J1939 layered architecture specifications – as defined by SAE

The Society of Engineers (SAE) has defined all the functions supported by different layers of the J1939 software stack.

.
J1939 Stack
.

Following are the details:

  • J1939/21 – Data Link/ Transport Layer: This layer defines the Message/Frame Format, Protocol Data Unit (PDU) Formats, Message Type, Message Priority, Bus Access, Arbitration, Error Detection, PGNs and Transport Protocol Functions
  • J1939/81 – Network Management Layer: This layer defines Name ECU, Address, Network Management Procedure, Network Error Management, Address Claim and ECU Initialization procedures
  • J1939/71 – Vehicle Application Layer: This layer defines Parameter Group Numbers (PGNs), Suspect Parameter Numbers (SPNs) with the Scaling, Limits and Parameter Offset Size. 
  • J1939/73 – Application Layer for Diagnostics services: This layer defines Diagnostic Trouble Codes (DTC), Diagnostic Parameter Group Definitions and Diagnostic Messages (DM)
    (Source: SAE)

What is Diagnostic Trouble Code (DTC) in J1939 stack?

When certain failure occurs in an automotive ECU, it is noted in the form of a Diagnostic Trouble Code (DTC), also known as Fault Code. DTCs’ are defined by SAE J1939 standard.

Diagnostic Trouble Code (DTC) has the following fields:

.
DTC In J1939
.

Where:

SPN is Suspect Parameter Number (19 bits)

FMI is Failure Mode Identifier (5 bits)

OC is Occurrence Count (7 bits)

CM is SPN Conversion Method (1 bit).

With help of DTC one can understand failure that has been reported.

For Example:

SPN = 91 Suspect parameter is accelerator pedal position

FMI = 3 Failure mode is identified as voltage above normal

OC = 9 Occurrence count indicates trouble has occurred 9 times

CM = 0 Conversion Method is Intel.

What are Diagnostic Messages (DM) in J1939 software stack?

Diagnostic Messages are messages which give information about the health of the system, intimating about the malfunctions which have currently occurred in the automotive system.

Following are the examples of some of the Diagnostic Messages (DM) in J1939:

  • DM1 Message (Active Diagnostic Trouble Codes):

Diagnostic Message 1 (DM1) reports active diagnostic codes that are preceded by the diagnostic lamp status in the message byte. It reports diagnostic condition of the automotive ECU over the In-Vehicle Network with Suspect Parameter Number, Failure Mode Identifier and Occurrence Count.

  • DM2 Message (Previously Active Diagnostic Trouble Codes):

Diagnostic Message 2 (DM2) reports previously active diagnostic codes that are preceded by the diagnostic lamp status in the message byte. It reports diagnostic condition of the Automotive ECU over the in-vehicle network with same details.

  • DM3 Message (Diagnostics Data Clear):

This message indicates that all the Diagnostic information pertaining to the previously active trouble codes should be cleared or non-active trouble codes should be reset. This ensures that the active trouble codes, which are present in ECU, are not impacted.

Get in touch with our J1939 stack development team:

For any queries regarding the J1939 software stack or automotive ECU and tooling applications, get in touch with our team. Send us your Queries

Know more about our J1939 stack solutions and services here


  • 0

Integration of J1939 stack with an advanced EPS system | Automotive Tier-I Supplier

 

The client, a trusted and reputed Automotive Tier-I Supplier of steering and driveline components, approached our Automotive Embedded Services team to resolve a very challenging embedded software development issue.

This hurdle was a grave one-it had the potential to derail the product roadmap of their futuristic Electronic Power Steering (EPS) system.

Here is the complete success story!

 

Business Challenge:

Our client had successfully embarked on their journey of designing an advanced Electronic Power Steering (EPS) system for Commercial vehicles. The following critical phases of product development lifecycle were already complete:

  • Hardware design based on DsPIC 30F4011 Microchip Platform
  • All the necessary components and hardware modules were identified and finalized as per the design needs
  • In-vehicle testing of the hardware was complete
  • EMI and EMC certification-related compliance was also successfully achieved
  • PCB manufacturing phase was completed

However, the customer encountered a major roadblock during software porting.Due to limited on-chip memory (RAM and ROM) of DsPIC 30F4011 platform, it became imperative for the customer to port highly-optimized embedded software to the EPS system.

Re-designing or changing the hardware platform would have impacted the bottomline of the project negatively, leading to substantial financial loss. Also, the DsPIC Microchip platform was best suited for the required EPS application, meaning that the only feasible resolution was an Optimized Embedded Software.

 

Embitel Solution: the re-usable and layered architecture based J1939 stack:

After several engineering workshops with the customer for understanding and analyzing the EPS system, Team Embitel was able to overcome the hurdle with the help of following solution:

  • A light-weight and re-usable SAE J1939 compliant stack best suited for commercial vehicles was integrated with the system
  • The entire code was optimized around J1939 stack and since the stack has layered architecture, the optimized software was successfully ported thus overcoming the memory issue

SAE J1939 – Project details:

  • SAE J1939 complaint Boot Loader was also ported to facilitate Reprogramming of ECUs efficiently and securely via CAN network
  • The ported J1939 stack consisted of J1939 Data Link and Transport Layer (J1939\21), Network Management layer (J1939/81), Vehicle Application Layer (J1939/71) and Vehicle Diagnostics Layer (J1939/73)
  • All this ensured support for vehicle communication, reprogramming, diagnostics and fault code memory
  • All the necessary device drivers were designed, developed and ported by Embitel
  • The EPS being an OS-independent system (non-RTOS), a Scheduler was also ported as shown in the system architecture diagram
  • Onsite support for integration of stack with client’s application and in-vehicle testing services were also extended as part of this successful engagement
  • J1939 stack also ensured Enhanced Portability for the steering system (Support for 8, 16 and 32 bit Embedded Controllers)
J1939-Stack
Embitel Impact:
  • Timely resolution of the software issue by designing a highly optimized and high quality code
  • Integration of re-usable J1939 stack not only safe-guarded the client’s product roadmap but also ensured speed-to-market and cost savings

What is SAE J1939?

Society of Automotive Engineers (SAE) J1939 is the vehicle bus recommended practice used for communication and diagnostics among vehicle components.

SAE J1939 is used in the commercial vehicle area for communication throughout the vehicle, with the physical layer defined in ISO 11898.

Source – Wikipedia