J1939 Stack Source Code

Embitel Technologies International presence:
How to Test Quality of J1939 Stack Source Code

If your technology R&D department is in search of an off-the-shelf J1939 software solution for ECU communication or
diagnostics applications then this article will be a good read.
Our J1939 software development team has shared a placid walk-through of the basic functions that needs to be tested, of
each layer of the protocol stack to ensure that you purchase a quality J1939 source code.
For starters, we will introduce J1939 software stack and understand the benefits of integrating pre-tested J1939 software
stack solution.
What is J1939 protocol software?
J1939 stack is a software solution developed to support seamless communication and diagnostic services within the in-
vehicle network (based on CAN bus protocol).
J1939 protocol based software stack is designed for commercial vehicle applications.
J1939 software stack is complaint to Society of Automotive Engineers (SAE) J1939 standard.
J1939 Software Source Code

Represented in the figure below, is the architecture of J1939 software stack
This automotive protocol stack has layered
software architecture based on seven-layer
ISO-OSI model.
The layers required to be configured and
integrated while porting the embedded
software depend on the requirement of the
specific automotive applications.
The consistent layers of the J1939 software
stack, available as off-the-shelf solution
include: Data link layer, Network management
layer and application layer.

.
J1939 stack is readily available as an off-the-shelf solution. A number of automotive engineering services and tool vendors
have launched their pre-packaged and pre-tested SAE J1939 solution.
Integration of such re-usable J1939 software solution with automotive and tooling applications ensures significant savings
in development time and cost.
Purchasing an off-the-shelf SAE J1939 protocol stack is a cost-effective option in scenarios similar to the following:
• As an automotive OEM or Supplier, your R&D team wants to focus on core product development activities.
• Your in-house R&D or embedded software development team do not have expertise in protocol stack design and
development.
• Your team is facing certain road-block during product development and there are time and cost constraints.
Partnering with a renowned embedded software development vendor also has an added advantage of testing, support and
maintenance services that are part of the engagement.
What are the benefits of integrating a verified and validated J1939 software stack?

Now that you have arrived at the decision of outsourcing or purchasing pre-tested SAE J1939 stack solution, it is important
that you invest in good quality software.
A pre-tested and pre-packaged J1939 software solution ensures you a re-usable stack, thus setting a benchmark among the
variety of other automotive software services vendors.
Validating or testing the layered architecture design of J1939 stack
As already mentioned, J1939 software stack typically consists of the following layers:
1. Data Link / Transport Layer (J1939/21)
2. Network Management Layer (J1939/81)
3. Vehicle Application Layer (J1939/71 & 73)

Data Link / Transport Layer:
1. Peer to Peer communication
2. Broadcast Announce Message
Network Management Layer:
1. Address Claim Message
• Self – Configurable Address
• Commanded Message
Vehicle Application Layer:
1. Tx and Rx of Standard SPNs packed in PGN’s.
Here are some of specific basic functions that need to be checked in each layers.

To test the specific functions of each layer, one can design certain test cases.
The derived outcomes indicate if the concerned layer has been designed as per the desired quality or not.
Checking for the aforementioned functionalities ensures an efficient and cost-effective J1939 stack.
J1939/21 – DataLink / Transport Layer:
1. Peer to Peer Transport Protocol: Peer to peer TP is a dedicated protocol in which the source and destination is
following a one-to-one (among ECUs) data transmission.
2. Broadcast Announce Message(BAM) : BAM is the acronym used for Broadcast Announce Message, generally used for
transmission of data greater than 8 bytes.
The BAM is a protocol that follows the one-to-many pattern of communication among the ECUs.
Both the peer to peer and BAM has a particular sequence and structure as defined by the SAE standard. We can validate
the structure and functionality using case scenarios and demo PGNs.
How to check the basic functions of different layers of J1939 solution?

J1939/81 -Network Management layer:
1. Address claim: Each device connecting to the network sends an immediate acknowledgement in form on address claim
message. Now, there can be conflicts in the addresses (duplicity) of the devices that send the address claim messages
to the network. This situation can be mitigated by two logical manipulations:
• Self-configurable address: The algorithm should affirm the ECU’s ability to randomly pick its own address in case
of conflict. The priority of the devices should be taken into consideration while address claiming during
integration of the stack with application.
• Commanded Message: This again is an algorithm specified message which claims the address according to the
input command.
While testing for the above functionality we make sure, the PGN to be tested satisfy the criteria of the test case.
For example:
To check address claim message, a CAN tool can be used. The ECU under test which is being ported with J1939 software
stack, should send the first message as an address claim message to claim the address on the network. Similarly test cases
can be checked for self-configurable and commanded message functionalities.

J1939/71 & 73- Vehicle Application Layer
Vehicle Application Layer of J1939 protocol stack manages transmitting and receiving of PGNs’ (Parameter Group Number)
messages within the in-vehicle CAN network.
Each PGN consists of various SPNs’ (Suspect Parameter Number) which are nothing but vehicle parameter data fetched from
the CAN network.
Such data (SPNs’) are received and transmitted by automotive ECUs’ (control units) through Vehicle Application Layer.
The J1939/71 & 73 protocol standard has a defined unique SPN for each vehicle parameter
For example – For engine RPM there is a pre-defined unique SPN mentioned in J1939/7x documents
For testing the source code of J1939 stack designed by an embedded services vendor, one needs to check if control units
within the network are able to accurately transmit and receive the data parameters stored in SPNs’
Let’s take an example of SPN 177, which represents Transmission Oil Temperature in PGN 65272.

It consists of two bytes of data. The value of Transmission Oil Temperature ranges from -273 to 1735 degree centigrade with
offset of 0.03125 deg C / bit.
With the help of a CAN Tool one can monitor the Tx& Rx of this SPN in PGN 65272 over a CAN Bus network
Change the values from minimum to medium range and to maximum range and check if it is being transmitted correctly
between the ECUs’ over CAN network.
The pre-tested layers of J1939 source code as informed in the testing guide above, will help you to make more informed
decision before outsourcing the software development project.
Contact us today for J1939 Source Code ! Mail us at sales@embitel.com

J1939 Stack Source Code

More Related Content

What's hot (20)

Similar to J1939 Stack Source Code (20)

More from Embitel Technologies - A VOLKSWAGEN GROUP COMPANY (20)

Recently uploaded (20)

J1939 Stack Source Code