YANMAR Technical Review

Automated Testing of Agricultural Machinery Control Software without Machinery: Hardware-in-the-Loop Simulator


Nowadays, the role of electronic control in agricultural machinery is increasing. Accordingly, the software used for electronic control has become more complex. As a result, the testing scope has expanded and the amount of work required for testing has increased. Therefore, we are facing some challenges, such as the difficulty in setting the conditions for software testing, and the time needed to finish all tests.

However, we solved these challenges by introducing a Hardware-in-the-Loop Simulator.

This report provides an overview of the Hardware-in-the-Loop Simulator and examples of its application.

1. Introduction

Yanmar has been working to improve the functionality and performance of agricultural machinery with the aim of achieving sustainable agriculture. Electronic control plays a big part in achieving these gains in functionality and performance. Fig. 1 shows the electronic control functions used in a large combine harvester. The functions are implemented using software running on the machine's electronic control units (ECUs) (see Fig. 2). The problem with using electronic control for a wider range of functions is that the greater functionality and performance means more complex software, expanding the scope of software testing and the amount of work required to complete it. To address this problem in its development of agricultural machinery, Yanmar has started using a hardware-in-the-loop simulator (HILS), a tool widely used in automotive development. This report describes how the HILS works, its benefits, and examples of its use in practice.

Fig. 1 Electronic Control in a Combine Harvester
Fig. 2 ECUs Used in Agricultural Machinery

2. Principle behind HILS Used by Yanmar

The HILS used by Yanmar passes signals generated in an actual machine to an ECU to test ECU operation under the same conditions as during actual use.

Fig. 3 shows a block diagram of the HILS setup. The HILS is made up of ECUs, hardware, simulation models, and a host PC.

The ECUs run the software program, sending and receiving electrical signals to and from the hardware via a wire harness.

The hardware converts between electrical signals and model values. That is, it measures electrical signals from the ECU and converts them into the values used in the model calculations. Similarly, electrical signals are output to the ECU based on the model values.

The model calculates how the actual machine would respond in practice based on the model values measured by the hardware and the inputs from the host PC. The results are sent back to the ECU via the hardware.

The host PC is used to enter model inputs, display calculation results, and monitor ECU input and output values. Inputs from the steering wheel and other controls on the actual machine are input via the host PC and passed to the ECU and model.

The model calculates how the actual machine would respond in practice based on the actuator signals output by the ECU and the inputs from the host PC. The results are passed to the ECU in the form of sensor signals. Using these signals and its software, the ECU outputs the next set of actuator signals. Through this loop, HILS allows ECUs to be tested as if they were mounted in the actual machine.

Fig. 3 Block Diagram of HILS
Fig. 4 HILS System

3. Benefits of HILS

3.1. Easily Replicate Complex Software Test Conditions

Although the software designed for agricultural machinery needs to be tested under a wide range of different conditions, including different modes of operation or environments, the safety considerations and the circumstances of testing mean that attempting to replicate these on an actual machine is sometimes difficult. While a tractor, for example, is operated using pedals and other controls, the variety of different settings for these controls means that the number of different combinations to be tested is very large. Similarly, surface conditions depend on things like ground wetness or slope, and these too have a wide range of variables. Furthermore, quality assurance requires that operation be tested in the presence of faults such as a broken wire (see Fig. 5). There is a limit to how many different real-world conditions, such as sloping terrain, etc. can be prepared for testing using the actual machine, and the safety of testing staff and others becomes an issue when deliberately introducing faults.

Because HILS is a simulator, it can be used to safely set up a variety of different circumstances as needed, making it easy to replicate a wide range of software test conditions.

3.2. Ability to Test Software as Needed

The time available for testing on an actual machine is limited. For example, testing may have to wait for the completion of a prototype or for the crop harvesting season. There are also cases when software bugs identified near the end of harvesting are not fixed until after the harvest is already over, meaning that testing cannot be done until the next harvest.

In contrast, when using HILS, software testing can proceed at any time, even if no actual machine is available, and conditions such as the presence or absence of crops can be simulated.

3.3. Ability to Automate Software Testing

As software becomes increasingly complex and the number of tests to be conducted increases, testing on an actual machine requires more people and takes more time.

HILS allows testing to be automated, with a PC used for operation and the viewing of results. Fig. 6 shows a block diagram of an automated test environment. By loading a test plan that specifies the control inputs and expected output, the host PC automatically generates the required inputs, uses the monitored values to assess performance, and then outputs the test results. This system enables software testing to be automated.

Fig. 5 Testing a Wide Variety of Conditions
Fig. 6 Block Diagram of Automated Testing

4. Examples of Applying HILS

The following sections describe practical examples in which the benefits of HILS were applied to testing during actual electronic control development.

4.1. Safety Testing with Simulated Faults (Robot Tractor)

The Robot Tractor can drive itself by using signals from GNSS satellites or base stations received via an antenna to determine its position and comparing this against a route created on a tablet computer.

HILS was used to test how the Robot Tractor responds to faults such as wires breaking during autonomous driving, and to confirm that the vehicle comes to a safe halt when such problems occur (see Fig. 7). While there are a wide variety of potential problems such as broken wires or abnormal signals etc., the ease with which these can be replicated using HILS ensured that software testing was comprehensive.

4.2. Functional Testing of Automatic Loss Control (Combine Harvester)

Large combine harvesters are equipped with an automatic loss control function that uses sensors to detect the loss of grain in the threshing and sorting processes and automatically controls the harvesting speed and sorting operation to minimize this loss (see Fig. 8).

Using HILS allows functional testing of automatic loss control to be performed outside of the harvest season. It also facilitates operational checks and testing of conditions subject to limited availability in an actual field. Such conditions include perimeter reaping in which the combine harvester is first driven around the outer edge of the field to provide space for it to turn around. It also includes the conditions at the moment in which the combine reaches the end of a row of crops and moves into the initially harvested perimeter area, thus transitioning from reaping to non-reaping state. In other words, it is possible to verify the quality of operations for which it is difficult to achieve comprehensive coverage when testing with an actual machine.

Fig. 7 Software Testing of the Robot Tractor
Fig. 8 Flow Chart for Automatic Loss Control

4.3. Reduced Testing Workload

The automation of software testing has shortened development times. The practice of launching automated testing overnight and checking the results on the following day has significantly improved the productivity of new model development compared to when everything was tested on an actual machine. Functional updates or additions that arise when developing product variants involve changes to software and require re-testing to check for any negative effects on existing functions. This is another area where automated testing using HILS makes for efficient development.

5. Conclusions and Future Plans

Amid the rising importance of electronic control to agricultural machinery, the issues that arise in the testing of the software used to implement this control include tests that are difficult to perform on an actual machine, tight testing schedules, and the increasing number of tests to be performed. Having forged ahead of other companies in the adoption of HILS for agricultural machinery in ways that simulate the entire machine, Yanmar has overcome these challenges and succeeded in both shortening test schedules and maintaining quality. In doing so, Yanmar has put the infrastructure in place that enables it to release high-quality products that match what customers want.

Electronic control is becoming ever more important in facilitating the ongoing supply of agricultural machinery with high added value to customers, and with this comes increasingly complex software. Accordingly, Yanmar intends to promote even greater use of HILS to ensure software quality. Furthermore, Yanmar also intends to deploy HILS technology beyond agricultural machinery to other Yanmar products, such as construction equipment and boats, to provide customers with high-quality and sophisticated functionality in a timely manner.


The original technical report is written in Japanese.

This document was translated by Research & Development Management Division.


Product Development Division 2
Electronic Control Development Division

Yu Kiyosawa