Validating firmware on a new controller for a mining vehicle

Challenge

The client was developing microcontroller firmware to manage part of their mining machine. This machine is too large and expensive to use for initial testing of the firmware. Instead, models were needed to simulate subsystems of the machine to test proper operation of firmware. And, the subsystems had to be sequenced through various states that the machine controller would encounter in actual use.

Solution

We developed a series of VeriStand models for the subsystems to run on a PXI RT controller. Then we  developed some TestStand sequences to “drive” the machine through a set of simulations by setting the VeriStand model parameters. The sequences ran through certain scenarios to check performance of the controller firmware to a known sequence of conditions while validating the controller actions.

We acted as an extension of our client’s engineering team. Our client had engineering capabilities in VeriStand and TestStand to do the work themselves but did not have the capacity for the work at the time.

Benefits

Working Together

Our initial engagement with this team dealt with requirements gathering. We discussed managing this project with traditional Waterfall methods, where requirements are completed before going to design, but it was decided to manage closer to an Agile methodology, where we defined a short-term goal and adjusted subsequent steps as we progressed.

The main reason for this choice was that our client was busy developing the firmware at the same time Viewpoint was developing the simulation models. In other words, they wanted to “get going” in order to highlight design issues earlier than later.

The fact that we both had experience and knowledge about VeriStand and TestStand, made the status discussions quite technical and productive. Consequently, Agile worked well for this project.

How we helped

We helped our client in the development of their controller firmware by offering:

System Overview

The models we developed had to adjust their internal state to simulate the motion of the machine. The models reacted to messages from the firmware and passed back appropriate responses to the microcontroller.

The messages adhered to the J1939 CAN protocol. The models communicated to the microcontroller via PXI-8512 NI-XNET CAN modules in the PXI chassis.

The VeriStand models were all developed in LabVIEW for deployment on the PXI RT target running the VeriStand Engine. We were able to leverage a VeriStand custom device for J1939 previously developed by NI and hosted on GitHub. This code was useful because we had to extend the standard X-NET for this project . TestStand, VeriStand, and some Python code ran on a separate PC connected to the PXI RT controller to round out the testing environment.

The vehicle model received some digital signals for low level safety redundancy in case somehow the comms stopped functioning. For example, a digital heartbeat was output and some digital signals from the controller were used to indicate low-level state such as E-stop.

The TestStand sequences covered a wide range of motion situations and we expect that our client will create additional sequences for different simulations once we’ve completed the system foundation and essential test plans.

This table lists the main components used in this test system.