A Novel Method for Idle-Stop-Start Control of Micro Hybrid Construction Equipment — Part B : A Real-Time Comparative Study

Micro hybrid propulsion (MHP) technologies have emerged as promising solutions for minimisation of fuel consumption and pollutant emissions of off-highway construction machines (OHCMs). Their performance and economic feasibility strongly depend on the way they utilize the idle-stop-start control (ISSC) concept. The ISSC design process and performance evaluation are particularly challenging due to the peculiar structures and dynamics of OHCMs compared to other vehicles and, therefore, require significant development time and efforts. This paper is the second of a two-part study focusing on prediction-based idle-start-stop control (PISSC) for micro hybrid OHCMs. In part A, the powertrain model and the procedure to design the PISSC system have been presented. The PISSC-based engine control performance has been investigated through numerical simulations with the designed model. In this Part B, a hardware-in-the-loop (HIL) test platform is established in HIL Control Laboratory for the rapid validation of the proposed technique in terms of the fuel/pollutant emission saving in real-time. First, the powertrain architecture and PISSC algorithm presented in Part A are briefly reviewed. Second, the process to build the HIL test platform is clearly stated. Third, experiments and analysis are carried out for a number of comparative studies to validate the superiority and practical applicability of the PISSC approach.


Introduction
In the past two decades, the use of fuel has not been considered a significant portion of construction firms' operating budgets.However together with the recent price rises and the fuel supply crisis, this is no longer the case [1].Most construction equipment fleet owners are now concerned with not only improving productivity, but also reducing the fuel consumption of their machines.Furthermore, pollutant emissions from this kind of machines has also strongly stimulated research and development activities on greener machines.
Among the technology roadmaps toward this objective, exploitation of micro hybrid propulsion (MHP), well implemented in automobiles [2][3][4][5][6][7][8], has been drawing more and more attention due to its advantages, including high energy performance, low fuel use and emissions while requiring low cost and effort for installation [9].For a MHP system, the key function is known as stop-start control (SSC) or idle-stop-start control (ISSC).This enables the internal combustion engine (ICE) to be automatically shut down (with both SSC and ISSC) or driven with low power consumption (only with ISSC) while working without load or with reduced workloads, respectively, and immediately turned on if needed.
In order to underpin the SSC/ISSC research theme of construction equipment, two critical issues need to be addressed.The first is how to detect whether or not a machine has a low or zero workload to make decisions to reduce power of the ICE or shut it down to avoid the unnecessary fuel use [10][11][12].The second is how to design an algorithm capable of recognizing periodically repeated working cycles of the machine, which are normal in many construction tasks, to make the engine control decisions sooner [12].This will therefore maximize the potential energy savings of the machine.These both two issues can be well resolved using the recent work described by the authors in part A of this project [12]-the so-called prediction-based idle-stop-start control (PISSC) which has been introduced for application to a micro hybrid excavator for the first-time.
Through the art presented in part A [12], the target machine has been discussed and the powertrain model has been properly constructed.The PISSC scheme has been then built to identify online the cyclic working profiles based on the machine states.This information is then used to predict any engine mode changes ahead of time.Consequently, the ICE can be switched almost directly into a new mode once the first few machine states of this mode are captured.The PISSC performance has been briefly validated with simulation results.In order to realize the proposed control approach in the production of an engine control unit (ECU) as well as to further identify the potential fuel and emissions saving of the machine using this approach, additional tests in real-time and a comprehensive analysis need to be done.However, time, costs and safety are the critical concerns for conducting this kind of tests and analysis directly on real construction equipment.
Hardware-in-the-loop (HIL) test platforms have been widely used by both researchers and original equipment manufacturers (OEMs) in terms of product design (hardware and software) and rapid prototyping.An HIL platform is based on system knowledge and mimics the operation conditions that the system will actually face in the real world.When performing a HIL experiment, a physical plant is then substituted by a precisely equivalent computer model, running in real-time on a hardware appropriately equipped with inputs/outputs (I/Os) capable of interfacing with control systems and other equipment.Thus, both the system modelling and control works can be then tested and/or validated quickly and safely in the real environment using this HIL setup.Hence, HIL testing methodology is the most time efficient and cost effective way to bring research and development of new systems and control algorithms one step closer to the real applications and productions [13].In vehicle development, the HIL test method is a well-known firm fixture in the product design progress as a method of testing electronic control unit software.Several commercial tool chains of HIL platforms for vehicles such as LABCAR, dSPACE, VeHIL or Autonomie are known [14].These kinds of tools can be utilized not only to test functionalities but also optimize the structure/parameters of one or even a network of control units [13,15].Consequently, they can improve the design success rate while eliminating the risk of development errors [14].Especially in industrial vehicles and off-highway machines where the supervisory controllers may contain more than 20 electronic control units connected to more than two controller area network (CAN) buses [15], HIL platforms capable of evaluating and/or optimizing the control system via CAN buses are indispensable to perform regression tests on multiple variants and multiple test cases quickly, safety and closely mimicking practical applications [16].
To address the challenge of verifying the PISSC strategy in actual conditions as well as acknowledging the importance of HIL-based testing method, this paper-the second half (Part B) of ous research on the PISSC concept focuses on a design of an advanced HIL test platform representative of a real construction machine with basic engine control functions and a real-time evaluation of the proposed methodology in terms of fuel and emission reduction.First, the powertrain architecture, modelling and PISSC strategy presented in [12] are briefly reviewed in Section 2. In the next section, the process to design the HIL test platform using dSPACE and CAN buses is clearly presented.Experiments and analysis on the HIL platform for a number of test cases and comparative control approaches are carried out in Section 4 to validate the superiority and practical applicability of the PISSC.Finally, concluding remarks are given in Section 5.

Powertrain Architecture
Based on the numerical analysis and evaluation from the experts on the ISSC potential of main construction machine classes, a typical heavy excavator from JCB has been selected as the target machine [12].Its powertrain is simply presented in Figure 1.The powertrain consists of an ICE, a DC starter, a DC alternator, a lead-acid battery, and a drivetrain including hydrodynamic and hydrostatic transmissions (HDT and HST), clutches and loads.The output shaft of the engine is coupled to the alternator by a belt transmission and then connected to the drivetrain.The starter with battery is used to crank the engine.During the ICE cranking phase, the starter-engine engagement is controlled by a pinion-ring gear mechanism and an over-running clutch.A solenoid valve is used to engage the pinion with the ring gear on a flywheel of the engine.During the machine operation, loads coming from the HST and HDT can be represented by a time-variant dynamic load connected to the engine output shaft.Specifications of the main powertrain components are given in Table 1 [9].

Powertrain Architecture
Based on the numerical analysis and evaluation from the experts on the ISSC potential of main construction machine classes, a typical heavy excavator from JCB has been selected as the target machine [12].Its powertrain is simply presented in Figure 1.The powertrain consists of an ICE, a DC starter, a DC alternator, a lead-acid battery, and a drivetrain including hydrodynamic and hydrostatic transmissions (HDT and HST), clutches and loads.The output shaft of the engine is coupled to the alternator by a belt transmission and then connected to the drivetrain.The starter with battery is used to crank the engine.During the ICE cranking phase, the starter-engine engagement is controlled by a pinion-ring gear mechanism and an over-running clutch.A solenoid valve is used to engage the pinion with the ring gear on a flywheel of the engine.During the machine operation, loads coming from the HST and HDT can be represented by a time-variant dynamic load connected to the engine output shaft.Specifications of the main powertrain components are given in Table 1 [9].     2 which is based on the ICE torque-speed bands to manage the engine operation [12]: • τ e and n e are the engine torque and speed, respectively.Their high, medium and low levels are in turn defined as: τ H e , τ M e , τ L e and n H e , n M e , n L e .

•
Normal mode (NOR): the machine requests the engine to run with full power capability.The starter does not operate during this mode.

•
Idle mode (IDL): the machine does not request the full engine power.The cylinder deactivation control technology can be employed to reduce the engine power.The starter does not operated during this mode.

•
Stop mode (STO): there is no command given from the human machine interface (HMI) module and the ICE torque and speed are below the low torque and speed levels, respectively (the ICE torque is mainly come from the system inertia).During this mode, the engine can be shut down to save the fuel and the starter is also turned off.

•
Start mode (STA): the engine is cranked from zero speed to its normal idle speed (around 900 rpm).The starter is firstly turned on to crank the engine to a low idle speed (around 250 rpm).At this low idle speed, the starter is turned off while the injector starts to inject fuel to continue to crank the engine to the desired idle speed.

•
A machine working cycle is a sequence of machine stages in which each machine stage is corresponding to one of the four defined ICE modes.The selection of ICE modes is performed by a rule-based controller.The PISSC-based engine control principle is described in Figure 3.The PISSC functions as the ICE speed controller which defines the working regions for the ECU.During operation, the signals from the HMI (including braking and acceleration commands from the pedals and actuator commands from joysticks) and ICE sensors (torque and speed) are acquired to determine the current ICE working mode using the ICE mode definition based on Remark 1.A timer is enabled to measure durations of the ICE modes which are then used to determine the machine working cycles.When a cyclic working profile is identified online, the grey prediction model (GPM) is activated to estimate the coming engine mode after only a few new machine states corresponding to a new ICE mode (compared to the current mode) are recorded.The prediction-based and timer-based mode decisions are both input to a rule-based controller (RBC) to make a final decision on ICE mode switching.This decision is then sent to the ECU in order to drive the engine in its highest fuel efficiency zone without sacrificing the machine performance.The PISSC-based engine control principle is described in Figure 3.The PISSC functions as the ICE speed controller which defines the working regions for the ECU.During operation, the signals from the HMI (including braking and acceleration commands from the pedals and actuator commands from joysticks) and ICE sensors (torque and speed) are acquired to determine the current ICE working mode using the ICE mode definition based on Remark 1.A timer is enabled to measure durations of the ICE modes which are then used to determine the machine working cycles.When a cyclic working profile is identified online, the grey prediction model (GPM) is activated to estimate the coming engine mode after only a few new machine states corresponding to a new ICE mode (compared to the current mode) are recorded.The prediction-based and timer-based mode decisions are both input to a rule-based controller (RBC) to make a final decision on ICE mode switching.This decision is then sent to the ECU in order to drive the engine in its highest fuel efficiency zone without sacrificing the machine performance.

Cycle Data Rolling Operation
This module includes three main functions: working cycle identification, raw data preparation and activation control for the GPM:

•
A working cycle can be then identified by the iterative searching algorithm proposed in [12].Once a periodic cycle is determined, the recorded machine stages are rearranged into a matrix form of cycle number, stages' indices and timestamps within a cycle.

•
For the cyclic operation, to estimate a coming machine stage (its index in the working cycle has been defined), a vector with n raw data points which are the timestamps of the same stage within n historical cycles is required.

•
The GPM is only activated when the recorded stage matrix contains historical data of n cycles.
If existing a new machine stage which is different from the defined stage sequence, the cycle definition is reset by removing the oldest machine stage and adding the newest one.The GPM is then de-activated and the search algorithm is applied again to identify the new working cycle.

Grey Prediction Model
Grey models are powerful estimation tools to deal with partially unknown systems [17][18][19][20][21].In this research, the grey prediction model has been built to estimate the ICE coming modes once the machine is repeatedly operated with the same cycle.The internal flow diagram of this GPM in combination with the cycle data rolling operation module in Figure 3 is described in Figure 4.The detailed mathematical equations of this GPM is clearly introduced in [12].Based on the grey theory [17,18,22], a minimum number of past data, more than four, is required to perform a grey prediction.Here, the GPM receives the historical timestamp vector of the coming machine stage (over the n historical cycles) to estimate the starting time of this stage at present.For each m repeated cycles (m ≥ n), duration of the first machine stage in the first cycle could be largely different from durations of this stage in the lateral cycles in case the first and last stages of a cycle are the same.Thus, n has

Cycle Data Rolling Operation
This module includes three main functions: working cycle identification, raw data preparation and activation control for the GPM:

•
A working cycle can be then identified by the iterative searching algorithm proposed in [12].Once a periodic cycle is determined, the recorded machine stages are rearranged into a matrix form of cycle number, stages' indices and timestamps within a cycle.

•
For the cyclic operation, to estimate a coming machine stage (its index in the working cycle has been defined), a vector with n raw data points which are the timestamps of the same stage within n historical cycles is required.

•
The GPM is only activated when the recorded stage matrix contains historical data of n cycles.
If existing a new machine stage which is different from the defined stage sequence, the cycle definition is reset by removing the oldest machine stage and adding the newest one.The GPM is then de-activated and the search algorithm is applied again to identify the new working cycle.

Grey Prediction Model
Grey models are powerful estimation tools to deal with partially unknown systems [17][18][19][20][21].In this research, the grey prediction model has been built to estimate the ICE coming modes once the machine is repeatedly operated with the same cycle.The internal flow diagram of this GPM in combination with the cycle data rolling operation module in Figure 3 is described in Figure 4.The detailed mathematical equations of this GPM is clearly introduced in [12].Based on the grey theory [17,18,22], a minimum number of past data, more than four, is required to perform a grey prediction.Here, the GPM receives the historical timestamp vector of the coming machine stage (over the n historical cycles) to estimate the starting time of this stage at present.For each m repeated cycles (m ≥ n), duration of the first machine stage in the first cycle could be largely different from durations of this stage in the lateral cycles in case the first and last stages of a cycle are the same.Thus, n has been selected as 6 [12] and the GPM only takes the most recent five data points to perform the prediction.Once a prediction is performed, the prediction accuracy is evaluated by comparing the estimated timestamp with the actual time at which the first machine state of this stage is detected.If the accuracy is within 5%, it means the machine keeps running with the same cycle and, the ICE mode decision and data rolling operation are executed based on the GPM output.The engine then is shifted to the new mode immediately.On the contrary, the machine may work with a new cycle and subsequently, the mode decision and data rolling operation need to be executed using the timer-based mode detection [12].In this case, the engine continuously runs in the current mode and, only can be shifted to the new mode after checking the machine states over a duration defined by the timer.
Energies 2017, 10, 1250 6 of 25 been selected as 6 [12] and the GPM only takes the most recent five data points to perform the prediction.Once a prediction is performed, the prediction accuracy is evaluated by comparing the estimated timestamp with the actual time at which the first machine state of this stage is detected.If the accuracy is within 5%, it means the machine keeps running with the same cycle and, the ICE mode decision and data rolling operation are executed based on the GPM output.The engine then is shifted to the new mode immediately.On the contrary, the machine may work with a new cycle and subsequently, the mode decision and data rolling operation need to be executed using the timer-based mode detection [12].In this case, the engine continuously runs in the current mode and, only can be shifted to the new mode after checking the machine states over a duration defined by the timer.

Rule-Based Controller
To support the RBC design, the following variables are defined: • HMI (HMI flag) is a variable which is unit if there exists at least a signal sent from the HMI module, and is zero vice versa.

•
TMR is value of the timer which counts number of continuous states of the engine which are within the same working mode, different from the current mode.This TMR is reset once having more than TMR new engine states or a new engine mode is selected.TMR is the pre-defined threshold value for TMR and, is the time in seconds needed to make a decision on ICE mode switching (in case the GPM is not activated).Here, TMR is selected as 3.

•
PRE is a variable representing a correct estimation of the GPM (if the estimation error is within a pre-defined acceptable range).Then, PRE = 1 if correct and PRE = 0 if not correct.

•
IGN is a variable representing the engine state, IGN = 1 if ICE is on and IGN = 0 if ICE is off.

Rule-Based Controller
To support the RBC design, the following variables are defined: • HMI (HMI flag) is a variable which is unit if there exists at least a signal sent from the HMI module, and is zero vice versa.

•
TMR is value of the timer which counts number of continuous states of the engine which are within the same working mode, different from the current mode.This TMR is reset once having more than TMR new engine states or a new engine mode is selected.TMR is the pre-defined threshold value for TMR and, is the time in seconds needed to make a decision on ICE mode switching (in case the GPM is not activated).Here, TMR is selected as 3.

•
PRE is a variable representing a correct estimation of the GPM (if the estimation error is within a pre-defined acceptable range).Then, PRE = 1 if correct and PRE = 0 if not correct.
• IGN is a variable representing the engine state, IGN = 1 if ICE is on and IGN = 0 if ICE is off.

•
SOC is the battery state of charge representing the energy remained in the battery (in percentage).
In order to enable stop-start operation, this SOC should be greater than a minimum level SOC min which allows the starter can crank the engine when STA mode is enabled.In this case, SOC min is set to 70%.
In this study, the prediction is only considered for the STO mode and the engine can be moved directly into NOR and IDL modes to adapt to the HMI commands.By updating all the declared variables and using Remark 1, four rules are then established for the RBC as follows: • Rule for NOR mode: the ICE is shifted to NOR mode if: • Rule for IDL mode: the ICE is shifted to IDL mode if: • Rule for STO mode: the ICE is shifted to STO mode if: • Rule for STA mode: the ICE is shifted to STA mode if:

Design Requirements and Specifications
The HIL platform is desired to perform two main tasks: • Rapid prototyping and validation of the engine control system for either traditional or hybrid (mainly micro/mild hybrid) propulsion mechanisms.

•
Functional and non-functional testing of different ISS-based engine control schemes, such as timer-based ISSC and prediction-based ISSC.
To meet these requirements, the following specifications need to be considered when designing the HIL system:

•
Rapid control prototyping tool chain: it is necessary to equip the HIL setup with a fast, efficient and flexible way of deploying, calibrating and validating of the developed control systems in a real-time environment.It also necessarily offers a re-use of plant models, control logics and data when moving between model-in-the loop (MIL) simulations and HIL experiments.

•
A graphic user interface (GUI) is needed to allow control developers to interact with the HIL system easily.In addition, functions for automatically performing experiments and data acquisition are essential to minimize the development time and efforts.Therefore, the HIL should be equipped with proper rapid control prototyping (hardware and software) tool chains.

•
Proper powertrain model for validation and analysis: in order to achieve reliable test results compared to the actual machine performance, it is required to use a high fidelity powertrain model which represents well the simulated system and is executable in real time to perform a closed-loop virtual reality environment.
• Real-time communication: to investigate the capability of the ICE control methods in actual working conditions, a CAN bus interface needs to be used for the data interaction between the powertrain model and control systems.

HIL Architecture
From the requirement and specification analysis, the HIL platform has been built in the HIL Control Laboratory at WMG-the University of Warwick using dSPACE machines as shown in Figure 5.
Here, a MicroAutoBox (MAB) with Real Time Interfaces (RTI) Blocksets (dSPACE, Wixom, MI, USA) and Simulink Coder of MATLAB (automatic code generation) (MathWorks, MA, USA) are utilized for building the ICE speed controllers as C-codes to run on the MAB.Each controller consists of the normal power control mode (of the traditional machine) and the ISSC mode (can be timer-based or prediction-based strategy).Meanwhile, a SCALEXIO with RTI multi-blocksets and ConfigurationDesk of dSPACE, and Simulink Coder are employed to generate the powertrain model's C-code for the SCALEXIO to represent the real system.In addition, C-codes of the HMI model and the environmental model are generated to support the control system validation.The MAB and SCALEXIO communicate via CAN buses which are based on the actual CAN interface of the real machine.Next, a personal computer (PC) installed ControlDesk is used to activate both the controllers and plant model and manage the interaction between these components.Furthermore, the system testing with data management is completely controlled by a simulation tool chain which will be discussed later.

Real-Time Powertrain Model
From the results in [12], the powertrain model can be constructed using the advanced co-simulation tool-AMESim (Siemens, Austin, TX, USA) and Simulink of MATLAB.This model is the combination of sub-models in which the sub-models of ICE, starter, pinion-ring gear and belt transmissions, external loads, and ECU are built in AMESim while the sub-models of battery, alternator and electrical load are built in Simulink using Simscape.For the MIL simulations in [12], by using the black-box model generation mode of AMESim, the AMESim model set was packaged as the black-box model and converted into the S-function.The major advancement of this model type is the capability of working independently in Simulink environment (without linking to AMESim), resulting in the shorter simulation time and the flexibility for control development.In this study for the HIL experiments, the AMESim model set constructed in [12] is converted into another S-function (having similar control utilities as the MIL one) using real-time code generation mode of AMESim.

Real-Time Powertrain Model
From the results in [12], the powertrain model can be constructed using the advanced co-simulation tool-AMESim (Siemens, Austin, TX, USA) and Simulink of MATLAB.This model is the combination of sub-models in which the sub-models of ICE, starter, pinion-ring gear and belt transmissions, external loads, and ECU are built in AMESim while the sub-models of battery, alternator and electrical load are built in Simulink using Simscape.For the MIL simulations in [12], by using the black-box model generation mode of AMESim, the AMESim model set was packaged as the black-box model and converted into the S-function.The major advancement of this model type is the capability of working independently in Simulink environment (without linking to AMESim), Energies 2017, 10, 1250 9 of 25 resulting in the shorter simulation time and the flexibility for control development.In this study for the HIL experiments, the AMESim model set constructed in [12] is converted into another S-function (having similar control utilities as the MIL one) using real-time code generation mode of AMESim.The generated S-function is then able to combine with the Simulink sub-models either to run in the real-time mode of MATLAB/Simulink or to enable the automatic code generation of the whole model to support the HIL experiments.The powertrain model is therefore completed in Simulink as depicted in Figure 6.The generated S-function is then able to combine with the Simulink sub-models either to run in the real-time mode of MATLAB/Simulink or to enable the automatic code generation of the whole model to support the HIL experiments.The powertrain model is therefore completed in Simulink as depicted in Figure 6.

CAN Interface
The CAN interface of the research machine is developed based on the AUTomotive Open System Architecture (AUTOSAR) [23] and demonstrated via Figure 7.As a standard control process, the machine control system can be divided into four layers: instrumentation (bottom layer, mainly consisting of machine actuators and sensors), low component control (electronic control units for basic functionalities and safety operations), supervisory control (such as the ICE speed controller and functions for low control loop interaction) and planning (top layer, including HMI for task assignment, performance visualization and data management).Due to the use of network communication, the sampling periods are defined differently as the orders of 10 millisecond seconds depending on the process control levels (increased with the rise of control level) to eliminate the network traffic as well as to maximize the overall machine performance.To deal with the complex machine structure with thousands of points, the communication module of the real machine is managed by two database CAN (dbc) files named M-CAN1 and M-CAN2 using the standard vehicle CAN protocol, SAE (Society of Automotive Engineers standard) J1939.These two dbc files are employed to define nodes with messages and their constituent signals

CAN Interface
The CAN interface of the research machine is developed based on the AUTomotive Open System Architecture (AUTOSAR) [23] and demonstrated via Figure 7.As a standard control process, the machine control system can be divided into four layers: instrumentation (bottom layer, mainly consisting of machine actuators and sensors), low component control (electronic control units for basic functionalities and safety operations), supervisory control (such as the ICE speed controller and functions for low control loop interaction) and planning (top layer, including HMI for task assignment, performance visualization and data management).Due to the use of network communication, the sampling periods are defined differently as the orders of 10 millisecond seconds depending on the process control levels (increased with the rise of control level) to eliminate the network traffic as well as to maximize the overall machine performance.The generated S-function is then able to combine with the Simulink sub-models either to run in the real-time mode of MATLAB/Simulink or to enable the automatic code generation of the whole model to support the HIL experiments.The powertrain model is therefore completed in Simulink as depicted in Figure 6.

CAN Interface
The CAN interface of the research machine is developed based on the AUTomotive Open System Architecture (AUTOSAR) [23] and demonstrated via Figure 7.As a standard control process, the machine control system can be divided into four layers: instrumentation (bottom layer, mainly consisting of machine actuators and sensors), low component control (electronic control units for basic functionalities and safety operations), supervisory control (such as the ICE speed controller and functions for low control loop interaction) and planning (top layer, including HMI for task assignment, performance visualization and data management).Due to the use of network communication, the sampling periods are defined differently as the orders of 10 millisecond seconds depending on the process control levels (increased with the rise of control level) to eliminate the network traffic as well as to maximize the overall machine performance.To deal with the complex machine structure with thousands of points, the communication module of the real machine is managed by two database CAN (dbc) files named M-CAN1 and M-CAN2 using the standard vehicle CAN protocol, SAE (Society of Automotive Engineers standard) J1939.These two dbc files are employed to define nodes with messages and their constituent signals To deal with the complex machine structure with thousands of points, the communication module of the real machine is managed by two database CAN (dbc) files named M-CAN1 and M-CAN2

Planning
Energies 2017, 10, 1250 10 of 25 using the standard vehicle CAN protocol, SAE (Society of Automotive Engineers standard) J1939.These two dbc files are employed to define nodes with messages and their constituent signals of the top two layers and the bottom two layers in Figure 7, respectively.Hence, the M-CAN1 and M-CAN2 are utilized for the intercommunication of the HIL system.The signal formats of the plant model's torque, speed and fuel consumption rate outputs and the HMI outputs required for the ICE speed controller (as its inputs) can be obtained directly from the messages of the two CAN buses.Meanwhile to support the utilization of the proposed ISSC approach, the following message is created and stored in the M-CAN1 for the ICE speed controller outputs:

•
The message called ISSC_cmds contains five signals which are sent to the ECU to drive the engine: ICE_crank_cmd, ICE_brake_cmd, ICE_ISS_enable, ICE_mode_cmd and ICE_speed_cmd.

•
ICE_crank_cmd (0 or 1, 1-bit length): a rising edge from 0 to 1 will activate the starter and injectors to crank the engine from zero to idle speed or working speed; on the contrary, a falling edge from 1 to 0 will shut down the engine.

•
ICE_ISS_enable (0 or 1, 1-bit length): a value of 1 will active the ISS-based engine control mode and, vice versa.

•
ICE_mode_cmd (0, 1 or 2, 2-bit length): the engine will run in NOR, IDL or STO mode if the value of ICE_mode_cmd is in turn 2, 1 or 0.

•
ICE_speed_cmd (0 to 100, 8-bit length): the ICE torque command is computed using the following relation (please note that, value of 1 corresponds to the maximum speed command): where: JX 1 , JY 1 , JX 2 and JY 2 are in turn the signals from the two 2-axis joysticks (within range [0, 100], to drive the hydraulic actuators of the machine); AP and BP are in turn the signals of the acceleration and brake pedals (within range [0, 100], to control the machine traction).
In addition, for the energy and emission performance analysis, another message named "ICE_emiss" is generated in the M-CAN2 for the plant model emission outputs.In summary, all the necessary messages and signals employed for the HIL system are summarized in Table 2.The cycle periods of all the signals are defined based on the machine control hierarchy (Figure 7) and the actual machine's CAN format, M-CAN1 and M-CAN2.

HIL Platform
In order to make the HIL test platform closer to real machine environment, it has been structured as displayed in Figure 8a.Two CAN channel sets (each set contains a CAN High and a CAN Low channel) have been selected from both the MAB and SCALEXIO to exchange the information between these machines.
Energies 2017, 10, 1250 11 of 25 The cycle periods of all the signals are defined based on the machine control hierarchy (Figure 7) and the actual machine's CAN format, M-CAN1 and M-CAN2.

HIL Platform
In order to make the HIL test platform closer to real machine environment, it has been structured as displayed in Figure 8a.Two CAN channel sets (each set contains a CAN High and a CAN Low channel) have been selected from both the MAB and SCALEXIO to exchange the information between these machines.As a closed-loop control system, the controller embedded in the MAB sends all the ICE driving commands to the plant model embedded in the SCALEXIO via CAN1 set and receives all the HMI signals and the ICE torque-speed responses via CAN2 set.Breakout boxes of both the MAB and SCALEXIO are used to perform the connection.To ensure the real-time operation as well as network traffic, the communication status between these two devices are monitored using a CANalyzer which is connected to the SCALEXIO and sends all the message transmissions and their states to the PC.The actual HIL setup is finally demonstrated in Figure 8b.

Simulation Tool Chain for MIL and HIL Testing
In order to minimize the user time and efforts, a simulation tool chain with a common user interface is necessary to enable users to configure and perform tests via either MIL or HIL method automatically.In this research, a simulation tool chain (shortened as STC) has been generated using MATLAB and Python scripts for automatic test case generation and automatic testing on both MIL and HIL platforms.The users do not need to interact directly with ConfigurationDesk and ControlDesk applications of dSPACE to perform the HIL tests.The structure of this STC is described in Figure 9.
Energies 2017, 10, 1250 12 of 25 As a closed-loop control system, the controller embedded in the MAB sends all the ICE driving commands to the plant model embedded in the SCALEXIO via CAN1 set and receives all the HMI signals and the ICE torque-speed responses via CAN2 set.Breakout boxes of both the MAB and SCALEXIO are used to perform the connection.To ensure the real-time operation as well as network traffic, the communication status between these two devices are monitored using a CANalyzer which is connected to the SCALEXIO and sends all the message transmissions and their states to the PC.The actual HIL setup is finally demonstrated in Figure 8b.

Simulation Tool Chain for MIL and HIL Testing
In order to minimize the user time and efforts, a simulation tool chain with a common user interface is necessary to enable users to configure and perform tests via either MIL or HIL method automatically.In this research, a simulation tool chain (shortened as STC) has been generated using MATLAB and Python scripts for automatic test case generation and automatic testing on both MIL and HIL platforms.The users do not need to interact directly with ConfigurationDesk and ControlDesk applications of dSPACE to perform the HIL tests.The structure of this STC is described in Figure 9.As shown in Figure 9, the STC firstly enables the user to input some key parameters, such as number of test cases, number of working cycles, control modes and model options.The STC allows As shown in Figure 9, the STC firstly enables the user to input some key parameters, such as number of test cases, number of working cycles, control modes and model options.The STC allows working cycles to be defined in a simple excel file format and to be re-used without adaptation in both MIL and HIL phases of development.By selecting a specific working cycle, corresponding test cases are automatically generated based on the defined number of test cases (discussed in the next section).All the projects and generated files are then created and organized in a default format.Next, depending on the selection of MIL or HIL test, closed-loop simulations are performed within the MATLAB/Simulink environment or real-time experiments are performed using dSPACE machines, respectively.A flag-based control logic is implemented to ensure the synchronous operation between the MAB and SCALEXIO.For each MIL test, the sampling rate is fixed at 10 ms while, for the HIL test, the communication is defined by the two dbc files and CAN interface (introduced in Section 3.2.3).In addition, data monitoring functions are supported during the tests.Especially with the HIL platform, a GUI consisting of a basic control panel for the user inputs (as demonstrated in Figure 10a) and a standard graph set of inputs and outputs of the system plant and controller (as demonstrated in Figure 10b-d) is self-generated to allow the user to interact directly with the HIL machines if necessary (such as to manually re-configure the platform or do specific tests).Finally, all the results are collected and analyzed using pre-defined key performance indicators (KPIs).These analyzed and standardized results are stored using MAT-file formats in MATLAB for an easy of access and reuse.

START
Energies 2017, 10, 1250 13 of 25 working cycles to be defined in a simple excel file format and to be re-used without adaptation in both MIL and HIL phases of development.By selecting a specific working cycle, corresponding test cases are automatically generated based on the defined number of test cases (discussed in the next section).All the projects and generated files are then created and organized in a default format.Next, depending on the selection of MIL or HIL test, closed-loop simulations are performed within the MATLAB/Simulink environment or real-time experiments are performed using dSPACE machines, respectively.A flag-based control logic is implemented to ensure the synchronous operation between the MAB and SCALEXIO.For each MIL test, the sampling rate is fixed at 10 ms while, for the HIL test, the communication is defined by the two dbc files and CAN interface (introduced in Section 3.2.3)In addition, data monitoring functions are supported during the tests.Especially with the HIL platform, a GUI consisting of a basic control panel for the user inputs (as demonstrated in Figure 10a) and a standard graph set of inputs and outputs of the system plant and controller (as demonstrated in Figure 10b-d) is self-generated to allow the user to interact directly with the HIL machines if necessary (such as to manually re-configure the platform or do specific tests).Finally, all the results are collected and analyzed using pre-defined key performance indicators (KPIs).These analyzed and standardized results are stored using MAT-file formats in MATLAB for an easy of access and reuse.For the control system investigation, a working cycle consisting of all the four working modes defined from [12] is employed and described in Table 4.As shown in this table, each row is a machine phase in the cycle corresponding to a specific working mode (which is automatically identified by the controller) while the columns are the timestamps of phases' starting, loads and HMI signals.An excel file with similar number of rows and columns is then built to represent this table.Next, two test scenarios have been then generated:

•
The first test scenario: the defined cycle is used to create N C continuously and repeatedly working cycles.Here, the first three phases of the defined cycle are only executed one time as they represent the operator first time entering the machine to turn it on manually via the ignition key.The remained phases are then repeated N C times to perform the first test case with N C cycles (the phase number 18 cycle n-th is connected to phase 4 of cycle (n + 1)-th).This scenario is utilized to investigate the differences between MIL results and real-time HIL results, and to compare the performance of the PISSC to the performances of the other control methods.

•
The second test scenario: a set of N T new working cycles are randomly generated from the one defined in Table 4 and stored in additional N T excel files in such a way that their first three phases and the total cycle durations are the same while the other 15 phases, 4 to 18 (or row 5th to row 19th in Table 4), are randomly mixed for different sequences with different phases' durations.These new cycles are then employed to construct N T corresponding test cases based on the same principle as the first scenario.This scenario is utilized to assessing the energy/emission saving capability of the proposed ICE control approach in different conditions.

Correlation between MIL and HIL Results
In this section, as the first stage of evaluating the machine performance and energy/emission saving potential using the designed simulation tool chain, the comparison between MIL and HIL tests has been carried out to ensure the reliability of the results.For this purpose, the first test scenario (defined in Section 4.1) was selected to simulate the system work tasks and loads while only one control option-the PISSC was chosen to drive the plant model.The total simulation time was set to 1558 s (N C = 14).
The simulation and real-time experiments with the same test case using the MIL and HIL platforms, respectively, were then performed.For the correlation examination, a continuous data set over one cycle period was extracted from the test results.In this case to show the uninterrupted working profile by repeating the defined cycle, data of cycle 7th from phases 6 to 18 and a part of cycle 8th (phases 4 and 5) have been selected and extracted from the whole test results.And the HMI inputs of this cycle were firstly compared as shown in Figure 11.As seen in this figure, at 770, phase 18th of cycle 7th was automatically linked to phase 4th of cycle 8th to perform the continuous test.The figure also indicates that the inputs (acceleration pedal, brake pedal and joystick signals) of the two tests were quite similar.There were only some small differences during the signal transitions, varied from 0.4% to 7% of the maximum signal level (100%).These were the signal delays caused by the different settings of sampling rates of the MIL (0.01 s) and HIL tests (0.1 s for HMI signals, as shown in Table 2).Next, the controller outputs and simulated ICE performances were carefully analyzed in order to evaluate the correlation between MIL and HIL results.
(defined in Section 4.1) was selected to simulate the system work tasks and loads while only one control option-the PISSC was chosen to drive the plant model.The total simulation time was set to 1558 s (NC = 14).
The simulation and real-time experiments with the same test case using the MIL and HIL platforms, respectively, were then performed.For the correlation examination, a continuous data set over one cycle period was extracted from the test results.In this case to show the uninterrupted working profile by repeating the defined cycle, data of cycle 7th from phases 6 to 18 and a part of cycle 8th (phases 4 and 5) have been selected and extracted from the whole test results.And the HMI inputs of this cycle were firstly compared as shown in Figure 11.As seen in this figure, at 770, phase 18th of cycle 7th was automatically linked to phase 4th of cycle 8th to perform the continuous test.The figure also indicates that the inputs (acceleration pedal, brake pedal and joystick signals) of the two tests were quite similar.There were only some small differences during the signal transitions, varied from 0.4% to 7% of the maximum signal level (100%).These were the signal delays caused by the different settings of sampling rates of the MIL (0.01 s) and HIL tests (0.1 s for HMI signals, as shown in Table 2).Next, the controller outputs and simulated ICE performances were carefully analyzed in order to evaluate the correlation between MIL and HIL results.

PISSC Outputs Correlation
The PISSC outputs of the MIL and HIL tests during the extracted period were firstly evaluated as shown in Figure 12.As seen in the second sub-plot from the top of this figure, the MIL and HIL ICE speed commands had slight differences which were similar to those of the HMI signals (plotted

PISSC Outputs Correlation
The PISSC outputs of the MIL and HIL tests during the extracted period were firstly evaluated as shown in Figure 12.As seen in the second sub-plot from the top of this figure, the MIL and HIL ICE speed commands had slight differences which were similar to those of the HMI signals (plotted in Figure 11).This was because the ICE speed command was derived directly from the HMI commands (using Equation ( 5)).Therefore, the differences only appeared during the transitions of speed command set points caused by the changes of HMI commands.Meanwhile, the other control outputs, including IEC cranking command, ICE brake command and ICE mode command (as depicted in the top and the last two sub-plots of Figure 12), were calculated using the PISSC logics (Section 2.2) based on the feedback ICE torque and speed.Different torque and speed profiles would lead to the different decisions on the control outputs and will be discussed in the next section.Herein, the ICE mode commands were assigned with values of 0, 1 and 2 which represented the STO, IDL and NOR modes (as shown in the bottom sub-plot of Figure 12, the STA mode was automatically integrated into NOR or IDL modes).
depicted in the top and the last two sub-plots of Figure 12), were calculated using the PISSC logics (Section 2.2) based on the feedback ICE torque and speed.Different torque and speed profiles would lead to the different decisions on the control outputs and will be discussed in the next section.Herein, the ICE mode commands were assigned with values of 0, 1 and 2 which represented the STO, IDL and NOR modes (as shown in the bottom sub-plot of Figure 12, the STA mode was automatically integrated into NOR or IDL modes).

ICE Dynamics Correlation
Next, in order to understand the control decisions as well as the resulted ICE performances, the correlation between MIL and HIL ICE dynamics were analyzed in Figure 13.Compared to the MIL result, there were some delays in the real-time simulated ICE speed, especially during the cranking periods.The maximum delay in the ICE speed response was about 2 s at the limited speed level.This problem came from the uses of sampling rates.The sampling rate was fixed at 10 ms for the MIL test while in the HIL test, the large sampling rates were used for the communication between the MAB (100 ms for the controller outputs) and SCALEXIO (20 ms for the plant model outputs) which represented the actual CAN architecture and setting of the real machine (as discussed in Section 3.2.3).As a result, this led to similar delay phenomena in the HIL-ICE torque (the second sub-plot of Figure 13) and, therefore, the HIL fuel consumption rate (the bottom sub-plot of Figure 13).In addition, due to the slower change of speed command, a slower speed response of the ICE in the HIL test compared to the MIL test resulted, and the simulated internal torques of ICE model, including inertia and friction torques, could lower than those of the MIL test [9].Thus, the amplitude of simulated ICE summing torque during HIL cranking could be lower than the MIL one, for example the period around 770 s.These torque and speed signals were sent back to the PISSC to derive the control outputs of the coming step.Subsequently, the ICE cranking, mode and brake commands of the HIL and MIL tests (in Figure 12) had lower consistency compared to the ICE speed commands.

ICE Dynamics Correlation
Next, in order to understand the control decisions as well as the resulted ICE performances, the correlation between MIL and HIL ICE dynamics were analyzed in Figure 13.Compared to the MIL result, there were some delays in the real-time simulated ICE speed, especially during the cranking periods.The maximum delay in the ICE speed response was about 2 s at the limited speed level.This problem came from the uses of sampling rates.The sampling rate was fixed at 10 ms for the MIL test while in the HIL test, the large sampling rates were used for the communication between the MAB (100 ms for the controller outputs) and SCALEXIO (20 ms for the plant model outputs) which represented the actual CAN architecture and setting of the real machine (as discussed in Section 3.2.3).As a result, this led to similar delay phenomena in the HIL-ICE torque (the second sub-plot of Figure 13) and, therefore, the HIL fuel consumption rate (the bottom sub-plot of Figure 13).In addition, due to the slower change of speed command, a slower speed response of the ICE in the HIL test compared to the MIL test resulted, and the simulated internal torques of ICE model, including inertia and friction torques, could lower than those of the MIL test [9].Thus, the amplitude of simulated ICE summing torque during HIL cranking could be lower than the MIL one, for example the period around 770 s.These torque and speed signals were sent back to the PISSC to derive the control outputs of the coming step.Subsequently, the ICE cranking, mode and brake commands of the HIL and MIL tests (in Figure 12) had lower consistency compared to the ICE speed commands.

ICE Emissions' Rates Correlation
Finally, the correlation of ICE emissions' rates between the MIL and HIL tests has been carried out and plotted in Figure 14.Like the fuel consumption rate variation, the HIL emission results were mostly similar to the MIL results but contained transition delays (maximum around 2 s during each cranking phase).It also pointed out that, by using the proposed idle-stop-start control logics, the fuel consumption rate (the bottom sub-plot of Figure 13) could be eliminated and therefore, the zero emissions could be achieved during the periods that machine worked with low load and without HMI commands.The correlation between MIL and HIL results were then summarized in Table 5.From this table, it can be seen that the largest differences came from the simulated ICE speeds and torque due to the used of actual CAN communication method.However, it did not impact heavily on the ICE fuel consumptions and emissions.This was because the main signal delays only came from the large machine state transitions during the cranking phases.The average fuel consumption and emissions differences of the two test methods varied around 1.9% to 3.7%, except the NOx and Soot emissions.Among the emissions, the difference in NOx levels was the highest with 6.693% although the NOx emission rate change was quite similar to the others (as shown in Figure 14).Meanwhile the Soot levels' difference was negative at −2.206%.The reason was these emissions were highly emitted during an ICE cranking phase.With a typical diesel engine, retarding fuel injection timing can effective reduce NO formation.However, this results in an increase of soot production, and vice versa [24].Therefore, the large mismatch between the MIL and HIL cranking resulted in the large variations of both NOx and Soot levels in the opposite direction.

ICE Emissions' Rates Correlation
Finally, the correlation of ICE emissions' rates between the MIL and HIL tests has been carried out and plotted in Figure 14.Like the fuel consumption rate variation, the HIL emission results were mostly similar to the MIL results but contained transition delays (maximum around 2 s during each cranking phase).It also pointed out that, by using the proposed idle-stop-start control logics, the fuel consumption rate (the bottom sub-plot of Figure 13) could be eliminated and therefore, the zero emissions could be achieved during the periods that machine worked with low load and without HMI commands.The correlation between MIL and HIL results were then summarized in Table 5.From this table, it can be seen that the largest differences came from the simulated ICE speeds and torque due to the used of actual CAN communication method.However, it did not impact heavily on the ICE fuel consumptions and emissions.This was because the main signal delays only came from the large machine state transitions during the cranking phases.The average fuel consumption and emissions differences of the two test methods varied around 1.9% to 3.7%, except the NO x and Soot emissions.Among the emissions, the difference in NO x levels was the highest with 6.693% although the NO x emission rate change was quite similar to the others (as shown in Figure 14).Meanwhile the Soot levels' difference was negative at −2.206%.The reason was these emissions were highly emitted during an ICE cranking phase.With a typical diesel engine, retarding fuel injection timing can effective reduce NO formation.However, this results in an increase of soot production, and vice versa [24].Therefore, the large mismatch between the MIL and HIL cranking resulted in the large variations of both NO x and Soot levels in the opposite direction.Overall, it can be concluded that the consistency between MIL and HIL results is acceptable and therefore, it proves the real-time applicability of the proposed control approach.

Comparison of ICE Performances Using Different Controllers
Next, the evaluation of the proposed control scheme over the other control schemes, CONC and TISSC, has been performed through the HIL experiments using the first test scenario during 1558 s.The prediction function of the PISSC was firstly validated.As presented in Section 2.2.2, the GPM was activated after 6 repeated cycles.The comparison of ICE performance during cycles 6 and 7 was carried out as in Figure 15.The result indicates that the prediction worked correctly from cycle 7th.The engine was then controlled by the predictor instead of the timer with 3-s threshold (Section 2.2.3).Subsequently, the engine was shut down almost immediately after the controller detected a few machine states.Thus comparing to the previous cycle, the additional fuel saving during around 3 s per cycle could be achieved from the 7th cycle (as depicted in the bottom sub-plot).Overall, it can be concluded that the consistency between MIL and HIL results is acceptable and therefore, it proves the real-time applicability of the proposed control approach.

Comparison of ICE Performances Using Different Controllers
Next, the evaluation of the proposed control scheme over the other control schemes, CONC and TISSC, has been performed through the HIL experiments using the first test scenario during 1558 s.The prediction function of the PISSC was firstly validated.As presented in Section 2.2.2, the GPM was activated after 6 repeated cycles.The comparison of ICE performance during cycles 6 and 7 was carried out as in Figure 15.The result indicates that the prediction worked correctly from cycle 7th.The engine was then controlled by the predictor instead of the timer with 3-s threshold (Section 2.2.3).Subsequently, the engine was shut down almost immediately after the controller detected a few machine states.Thus comparing to the previous cycle, the additional fuel saving during around 3 s per cycle could be achieved from the 7th cycle (as depicted in the bottom sub-plot).Next, the performance comparison between the three controllers was performed as shown in the following figures.Figure 16 displays the evaluation of controllers' outputs during the working cycle 7th.With the CONC, the engine was cranked only one time by the operator while the ICE brake and mode commands were always set to 0 and 2 during the experiment, respectively.The ICE power output was driven by only the HMI signals, represented by the speed command, and the loads.With the TISSC, the engine can be shifted in to idle or stop mode during the "zero" HMI commands and low load conditions (such as period 713 to 724 s or 753 to 764 s).This controller used the timer logics to make the decisions based on the ICE states over the 3-s sliding time windows (for examples, periods of 710 to 713 s and 750 to 753 s).Meanwhile as explained through Figure 15, the ICE mode decision was made quicker (around 3 s) using the proposed method.These differences resulted in the different ICE dynamics as shown in Figure 17.This figure shows that the significant amounts of unnecessary energy during the machine idle could be saved through the TISSC and PISSC.Herein, the fuel consumption was calculated by the ICE model which was based on the actual fuel consumption map of the engine given in Table 1.The injector control methodology (such as injection phase, time and speed) to optimize the engine consumption during low idle speed region is not the focus of this study.By using either the TISSC or PISSC, for low workloads, the engine could be shifted in to the IDL mode by deactivating one cylinder.Once there was no commands from the HMI and no external loads, the engine could be fully shut down as it worked with very low efficiency and zero productivity.As a consequence, the ICE emissions, including CO2, CO, HC, NOx and Soot, could be reduced by replacing the CONC (the solid-red lines) with either the TISSC (the dot-blue lines) or the PISSC (the dash-dot-magenta lines) as plotted in Figure 18.It also comes as no surprise that the PISSC could save more fuel and emissions compared to the TISSC due to the use of GPM.Next, the performance comparison between the three controllers was performed as shown in the following figures.Figure 16 displays the evaluation of controllers' outputs during the working cycle 7th.With the CONC, the engine was cranked only one time by the operator while the ICE brake and mode commands were always set to 0 and 2 during the experiment, respectively.The ICE power output was driven by only the HMI signals, represented by the speed command, and the loads.With the TISSC, the engine can be shifted in to idle or stop mode during the "zero" HMI commands and low load conditions (such as period 713 to 724 s or 753 to 764 s).This controller used the timer logics to make the decisions based on the ICE states over the 3-s sliding time windows (for examples, periods of 710 to 713 s and 750 to 753 s).Meanwhile as explained through Figure 15, the ICE mode decision was made quicker (around 3 s) using the proposed method.These differences resulted in the different ICE dynamics as shown in Figure 17.This figure shows that the significant amounts of unnecessary energy during the machine idle could be saved through the TISSC and PISSC.Herein, the fuel consumption was calculated by the ICE model which was based on the actual fuel consumption map of the engine given in Table 1.The injector control methodology (such as injection phase, time and speed) to optimize the engine consumption during low idle speed region is not the focus of this study.By using either the TISSC or PISSC, for low workloads, the engine could be shifted in to the IDL mode by deactivating one cylinder.Once there was no commands from the HMI and no external loads, the engine could be fully shut down as it worked with very low efficiency and zero productivity.As a consequence, the ICE emissions, including CO 2 , CO, HC, NO x and Soot, could be reduced by replacing the CONC (the solid-red lines) with either the TISSC (the dot-blue lines) or the PISSC (the dash-dot-magenta lines) as plotted in Figure 18.It also comes as no surprise that the PISSC could save more fuel and emissions compared to the TISSC due to the use of GPM.The ICE performances using the compared controllers were then numerically analyzed through a set of KPI factors, including the ICE stop/start numbers with durations, amounts of fuel used/saved with their costs, and emission factors with their saving amounts, as shown in Table 6.As seen in this table, the CONC without ISS function did not perform any stop-start action.There was only 0.14 s of ICE stop time because of the delay in ICE response when the machine was started the first time manually by the operator.With both the TISSC and PISSC, the number of ICE stop-start during the whole test was 28 (or, two times per cycle).The ICE run time was therefore reduced from 1553.87 s (with the CONC) to 1243.78 s (with the TISSC).Compared to the CONC performance, the TISSC could lead to a fuel savings of 0.329 L (equivalent to a saving of £0.382, while considering only stop-start) and 3.111 L (equivalent to a saving of £3.609, while considering the impact of idle-stop-start) over the whole test.By utilizing the PISSC method, the ICE stop time could be extended to 356.41 s resulting in to an additional fuel saving of 20.974% compared to the TISSC (equivalent to an additional saving of £0.118 over 14 cycles).Furthermore, with the use of ISS control techniques, the emissions were remarkably decreased.More than 43% of CO2, CO, HC and soot was cut-off while that of NOx was around 29%.This was because the engine only emitted small amounts of NOx during low idles (with slow injection rate).Through all the KPI factors, the PISSC showed its superiority in managing the ICE operation over both the CONC and TISSC.The ICE performances using the compared controllers were then numerically analyzed through a set of KPI factors, including the ICE stop/start numbers with durations, amounts of fuel used/saved with their costs, and emission factors with their saving amounts, as shown in Table 6.As seen in this table, the CONC without ISS function did not perform any stop-start action.There was only 0.14 s of ICE stop time because of the delay in ICE response when the machine was started the first time manually by the operator.With both the TISSC and PISSC, the number of ICE stop-start during the whole test was 28 (or, two times per cycle).The ICE run time was therefore reduced from 1553.87 s (with the CONC) to 1243.78 s (with the TISSC).Compared to the CONC performance, the TISSC could lead to a fuel savings of 0.329 L (equivalent to a saving of £0.382, while considering only stop-start) and 3.111 L (equivalent to a saving of £3.609, while considering the impact of idle-stop-start) over the whole test.By utilizing the PISSC method, the ICE stop time could be extended to 356.41 s resulting in to an additional fuel saving of 20.974% compared to the TISSC (equivalent to an additional saving of £0.118 over 14 cycles).Furthermore, with the use of ISS control techniques, the emissions were remarkably decreased.More than 43% of CO 2 , CO, HC and soot was cut-off while that of NO x was around 29%.This was because the engine only emitted small amounts of NO x during low idles (with slow injection rate).Through all the KPI factors, the PISSC showed its superiority in managing the ICE operation over both the CONC and TISSC.

Analysis on Fuel and Emission Saving Potential
Finally, to confirm the capability of the designed PISSC strategy, the fuel and esmission saving potential of the proposed ICE control aproach has been assessed through a series of real-time tests with different test cases.The second test scenario (Section 4.1) was used to generate randomly ten working cycles from the orgininal cycle (Table 4).Due to the differences in sequences and durations of the machine phases (the total cycle durations were still the same), the fuel economy and saving potential of the machine could be directly affected.By using these working cycles, the corresponding ten test cases were generated to perform the ten real-time tests with the PISSC on the HIL platform for 14 cycles.
By selecting some KPI factors defined in Table 7 and defining a new KPI named "Stop/Run Ratio" (denotes the ratio between the total ICE stop time and run time in %), the simulated performances of the engine have been summarized in Table 7.The analysis pointed out that the number of ICE stop-start was significantly depended on the duration of machine in idles and the setting of timer-threshold.In this case, the ICE would not be stopped if the engine stayed less than 3 s in idle conditions without loads and HMI commands (as shown in Test 1 and Test 3).With the remained tests, the stop/run ratio was varied from a minimum of 6.948% to a maximum of 35.274%.By linking to the KPI analysis in Table 6, it can be evidently concluded that the proposed PISSC has strong ability and capability for real-time ICE control to minimize the fuel consumption and emissions of the engine.

Conclusions
As the two parts of the study on the innovative energy management strategy-PISSC for OHCMs (with the concept proposed in Part A [12]), its real-time performance has been carefully investigated in this Part B. The HIL test platform is properly developed using dSPACE machines and CAN communication method for the rapid design and validation of different ICE control methods in the actual real-time environment.The simulation tool chain has been built to allow the automatic generation of the MIL and HIL tests and automatic data observation and analysis.The correlation between MIL and HIL results has been firstly assessed to prove the applicability of the designed control approach.Next, the dominance of the PISSC over the conventional approach and TISSC in managing the ICE operation has been validated through the number of real-time tests with the KPI analysis.Finally, the capability of the PISSC in terms of energy and emission saving has been proven by the numerical analysis over the test series with random test cases.
As the statistic calculation in [12] based on the reports of the US construction sector market [25], a 10% of fuel saving of OHCMs around the world could lead to a huge reduction of 35.42 million metric tons of CO 2 evaporating into the atmosphere.From the HIL results in Table 7, an average of 15.742% of machine operation due to idle could be cut-off by using the PISSC technique.Associating this factor with the machine stop and run times in Table 6 and using a simple linear interpolation, a corresponding amount in excess of 30% of total fuel consumption could be saved by replacing the CONC with the PISSC.Hence, this result affirms convincingly that the proposed approach offers high potential for energy and emission saving targets in the off-highway sector.
As a future research direction of this study, three main activities will be carried out.First, the integration of PISSC and the engine start control method developed by the authors in [9] will be taken into account for the smooth ICE start and the development of micro/mild hybrid machines.Second, a sensitivity study on the timer-threshold setting for the ICE stop decision will be done to improve the performance of the proposed control approach.Third, an 11-ton excavator has been selected to implement and validate the PISSC logics in actual construction tasks.

Figure 4 .
Figure 4. Flow diagram of the cycle data rolling operation and GPM modules in Figure 3 [12].

Figure 4 .
Figure 4. Flow diagram of the cycle data rolling operation and GPM modules in Figure 3 [12].

Figure 5 .
Figure 5. Structure of the HIL system.

Figure 5 .
Figure 5. Structure of the HIL system.

Figure 7 .
Figure 7. Hierarchical decomposition and CAN structure of the machine control system.

Figure 7 .
Figure 7. Hierarchical decomposition and CAN structure of the machine control system.

Figure 7 .
Figure 7. Hierarchical decomposition and CAN structure of the machine control system.

Figure 9 .
Figure 9. Working principle of the simulation tool chain.

Figure 9 .
Figure 9. Working principle of the simulation tool chain.

1
Machine key is with three positions: 0 (machine off), 1 (machine on), 2 (manual ignition); 2 Simulated load applied to ICE shaft = ICE internal load (inertia and frictions come from the model) + M × A pre-defined external load/100; 3 Simulated electrical load = E × A predefined electrical load/100.

Figure 11 .
Figure 11.Comparison of HMI inputs and loads of MIL and HIL tests during cycle 7th.

Figure 11 .
Figure 11.Comparison of HMI inputs and loads of MIL and HIL tests during cycle 7th.

Figure 12 .
Figure 12.Comparison of PISSC outputs of MIL and HIL tests during cycle 7-th.

Figure 12 .
Figure 12.Comparison of PISSC outputs of MIL and HIL tests during cycle 7-th.

Figure 13 .
Figure 13.Comparison of ICE dynamics of MIL and HIL tests during cycle 7th.

Figure 13 .
Figure 13.Comparison of ICE dynamics of MIL and HIL tests during cycle 7th.

Figure 14 .
Figure 14.Comparison of ICE emission rates of MIL and HIL tests during cycle 7th.

Figure 14 .
Figure 14.Comparison of ICE emission rates of MIL and HIL tests during cycle 7th.

Figure 15 .
Figure 15.Comparison of ICE dynamics of HIL tests using PISSC during cycles 6th and 7th.

Figure 15 .
Figure 15.Comparison of ICE dynamics of HIL tests using PISSC during cycles 6th and 7th.

Figure 16 .
Figure 16.Comparison of HIL-ICE control inputs using difference controllers during cycle 7th.

Figure 17 .Figure 18 .
Figure 17.Comparison of HIL-ICE dynamics using difference controllers during cycle 7th.Figure 17.Comparison of HIL-ICE dynamics using difference controllers during cycle 7th.

Figure 18 .
Figure 18.Comparison of HIL-ICE emission rates using difference controllers during cycle 7th.

Table 1 .
Specifications of the main powertrain components.
[12]PISSC-Based Engine Control Design ReviewRemark 1.For the PISSC design, four ICE working modes are defined as displayed in Figure2which is based on the ICE torque-speed bands to manage the engine operation[12]:• eτ and e n are the engine torque and speed, respectively.Their high, medium and low levels are in turn defined as:, , n n n .

Table 1 .
Specifications of the main powertrain components.
2.2.PISSC-Based Engine Control Design ReviewRemark 1.For the PISSC design, four ICE working modes are defined as displayed in Figure

•
Normal mode (NOR): the machine requests the engine to run with full power capability.The starter does not operate during this mode.•Idlemode(IDL):themachinedoes not request the full engine power.The cylinder deactivation control technology can be employed to reduce the engine power.The starter does not operated during this mode.•Stopmode(STO):there is no command given from the human machine interface (HMI) module and the ICE torque and speed are below the low torque and speed levels, respectively (the ICE torque is mainly come from the system inertia).During this mode, the engine can be shut down to save the fuel and the starter is also turned off.•Startmode (STA): the engine is cranked from zero speed to its normal idle speed (around 900 rpm).The starter is firstly turned on to crank the engine to a low idle speed (around 250 rpm).At this low idle speed, the starter is turned off while the injector starts to inject fuel to continue to crank the engine to the desired idle speed.
• A machine working cycle is a sequence of machine stages in which each machine stage is corresponding to one of the four defined ICE modes.The selection of ICE modes is performed by a rule-based controller.

Table 2 .
CAN message-signal design for HIL system.

Table 4 .
A simulated working cycle for heavy excavator.

Table 5 .
Summary of correlation between MIL and HIL results during cycle 7th.

Table 5 .
Summary of correlation between MIL and HIL results during cycle 7th.

Table 6 .
KPI analysis for the ICE performances using different controllers after 14 cycles.

Table 6 .
KPI analysis for the ICE performances using different controllers after 14 cycles.

Table 7 .
Summary of the PISSC-based ICE performances with respect to 10 random test cases after 14 cycles.