HELLA IBS 24V: How to Log LIN Bus Battery Data [+ LDF/DBC]

What problem did you solve?

We often encounter engineers that need to collect data from a popular Intelligent Battery Sensor, the HELLA IBS. The sensor comes in different variants (12V, 24V) and millions are deployed across automotive use cases. The sensor measures key parameters like current, voltage, State of Charge (SoC%), State of Health (SoH), battery temperature and more.

The data from the HELLA IBS is communicated via a LIN bus interface (Local Interconnect Network). In some cases, the HELLA IBS is deployed as a LIN slave in a LIN cluster with an existing LIN master. In other use cases, the sensor is retrofitted e.g. for ad hoc data collection. In this case, a dedicated LIN master is required to enable the communication.

This makes the CANedge 2 x CAN/LIN data logger ideal for recording LIN data from the HELLA IBS, as the device can act as either a LIN slave or LIN master.

1: Installation

For this basic installation we use open wire cables to connect the CANedge to the HELLA IBS. Specifically, we connect the CANedge Channel 1 pins as follows: Pin 3 (GND) to the battery pack ground, pin 4 (LIN data) to pin 2 of the HELLA IBS and pin 9 (supply) to the battery pack supply.

Further, we connect the IBS pin 1 (supply) to the battery pack supply and the IBS ground pin to the battery ground.

For more permanent in-field installations, it can be useful to create a custom wiring harness for the HELLA connector, e.g. utilizing a Hirschmann automotive connector or similar.

2: Configuring the CANedge

The next step is to configure the CANedge. In this test setup, the LIN cluster consists of a LIN master (the CANedge) and a LIN slave (the HELLA IBS). This means that we need to configure the CANedge with a 'schedule table' as described in our intro to LIN.

To do so, we use the LIN Description File (LDF) that comes with the HELLA IBS package. You can find the LDF in our LIN data pack above. The LDF provides all the necessary details related to the LIN communication, incl. details on LIN frames, signals and schedule tables.

At this stage, we extract the following from the LDF:

1. The IBS is LIN 2.x and thus uses enhanced checksums
2. The bit-rate is 19.2 kbps
3. A schedule table called 'IBS_LIN_Normal' for data collection
4. The Frames section with frame IDs and lengths

Based on this information we can fill out two key sections of the CANedge LIN CH1 configuration. First, we set the Mode to Publisher, as we want the CANedge to act as the LIN master. We also specify the bit-rate to match the LDF.

Next, we specify the LIN frames that will be communicated on the LIN bus. Some LIN nodes communicate frames where the frame length in bytes is linked to the LIN ID, so that e.g. a frame with a length of 2 bytes would have an ID in the range of 0 to 31 (decimal). However, the HELLA IBS does not adhere to this and we therefore need to explicitly inform the CANedge about the length of each frame as shown in the frame table.

Finally, we need to enter the LIN schedule table. This part enables the CANedge to transmit LIN headers to poll the HELLA IBS. It also allows us to specify payloads in cases where the CANedge itself provides information.

As evident from the LIN transmit list, the entered messages match the schedule table from the LDF, with a 50 ms offset between each of the frames. Note also that we leave the data payloads empty for all frames (as these are populated by the HELLA IBS), except for the SG_BatteryConfig frame. The payload of this frame is provided by the LIN master to inform the HELLA IBS of the battery specifications.

Creating the payload for the SG_BatteryConfig is semi-complex. First, you need to know certain properties of the battery pack, including the parameters like the nominal capacity (Ah) and min/max voltage levels (V). Typically, this information can be found in the datasheet of the battery. It is also our expectation that if the parameters are set at 'reasonable levels' it will suffice for most logging use cases.

Next, this information has to be encoded correctly into a raw LIN data payload. This effectively consists of the reverse process of decoding a LIN signal, using the decoding information from the LDF. To help simplify this process, our LIN data pack includes a small Python script for performing the encoding.

Once the static configuration payload is determined, the CANedge Configuration File is ready-to-use and can be added onto the device SD card.

When we power on the system, the CANedge will now initiate the communication with the HELLA IBS and the standalone deployment can be left running for any period of interest.

3: Decoding and visualization

We leave the CANedge to record LIN data for about 12 hours while the battery pack is discharging. After this, we disconnect the CANedge from power and collect the resulting MF4 log file from the SD card of the device. If we open this file in the asammdf GUI, we can view the raw LIN bus trace as shown in the picture. Here you can see that the various LIN frames indeed get populated with data as expected.

To decode the data, you can proceed in a number of ways:

• If you use our MF4 converters, you can 'finalize' the raw log file and open it in Vector tools, allowing you to directly decode the data to physical values with the HELLA IBS LDF file
• Alternatively, you can create a DBC file based on the LDF as described in our intro to LIN Description Files. We provide an example of this in our LIN data pack. This DBC file can be loaded in e.g. the asammdf GUI to decode the raw LIN data

If we go with the latter, we can plot the decoded LIN signals as shown in the asammdf screenshot. As expected, we can see the State of Charge (%) decline over the 12 hours of logging.

We can also use the DBC file to decode the LIN data with our MF4 decoders. This allows us to create a Parquet data lake and visualize the data in Grafana dashboards. You can see this in action via our HELLA IBS Grafana dashboard playground.