How to Test Quality of J1939 Software Source Code

How to Test Quality of J1939 Software 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.

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.

Represented in the figure below, is the architecture of J1939 software stack:

Source: https://www.embitel.com/blog/embedded-blog/what-is-j1939-software-stack

What are the benefits of integrating a verified and validated J1939 software stack?

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.

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)

Here are some of the specific basic functions that need to be checked in each of these layers.

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.

How to check the basic functions of different layers of J1939 solution?

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.

For example:

We can check for transport Broadcast Announce Message using CAN tool, by checking if the ECU (electronic control unit) under test, is transmitting BAM Message with 8 bytes of data message.

These 8 bytes should encompass the first message as sequence number and remaining 7 bytes are data.

Also unused data bytes of last transport data packet should be filled with 0xFF, according to ideal scenario.

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.