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
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
