Hardware-in-the-loop simulation




Hardware-in-the-loop (HIL) simulation, or HWIL, is a technique that is used in the development and test of complex real-time embedded systems. HIL simulation provides an effective platform by adding the complexity of the plant under control to the test platform. The complexity of the plant under control is included in test and development by adding a mathematical representation of all related dynamic systems. These mathematical representations are referred to as the “plant simulation”. The embedded system to be tested interacts with this plant simulation.




Contents






  • 1 How HIL works


  • 2 Uses


    • 2.1 Enhancing the quality of testing


    • 2.2 Tight development schedules


    • 2.3 High-burden-rate plant


    • 2.4 Early process human factors development




  • 3 Use in various disciplines


    • 3.1 Automotive systems


    • 3.2 Radar


    • 3.3 Robotics


    • 3.4 Power systems


    • 3.5 Offshore systems




  • 4 References


  • 5 External links





How HIL works


A HIL simulation must include electrical emulation of sensors and actuators. These electrical emulations act as the interface between the plant simulation and the embedded system under test. The value of each electrically emulated sensor is controlled by the plant simulation and is read by the embedded system under test (feedback). Likewise, the embedded system under test implements its control algorithms by outputting actuator control signals. Changes in the control signals result in changes to variable values in the plant simulation.


For example, a HIL simulation platform for the development of automotive anti-lock braking systems may have mathematical representations for each of the following subsystems in the plant simulation:[1]




  • Vehicle dynamics, such as suspension, wheels, tires, roll, pitch and yaw;

  • Dynamics of the brake system’s hydraulic components;

  • Road characteristics.



Uses


In many cases, the most effective way to develop an embedded system is to connect the embedded system to the real plant. In other cases, HIL simulation is more efficient. The metric of development and test efficiency is typically a formula that includes the following factors:
1. Cost
2. Duration
3. Safety
4. Feasibility


The cost of the approach should be a measure of the cost of all tools and effort. The duration of development and testing affects the time-to-market for a planned product. Safety factor and development duration are typically equated to a cost measure. Specific conditions that warrant the use of HIL simulation include the following:



  • Enhancing the quality of testing

  • Tight development schedules

  • High-burden-rate plant

  • Early process human factor development



Enhancing the quality of testing


Usage of HiLs enhances the quality of the testing by increasing the scope of the testing.
Ideally, an embedded system would be tested against the real plant, but most of the time the real plant itself imposes limitations in terms of the scope of the testing. For example, testing an engine control unit as a real plant can create the following dangerous conditions for the test engineer:



  • Testing at or beyond the range of the certain ECU parameters (e.g. Engine parameters etc.)

  • Testing and verification of the system at failure conditions


In the above-mentioned test scenarios, HIL provides the efficient control and safe environment where test or application engineer can focus on the functionality of the controller.



Tight development schedules


The tight development schedules associated with most new automotive, aerospace and defense programs do not allow embedded system testing to wait for a prototype to be available. In fact, most new development schedules assume that HIL simulation will be used in parallel with the development of the plant. For example, by the time a new automobile engine prototype is made available for control system testing, 95% of the engine controller testing will have been completed using HIL simulation[citation needed].


The aerospace and defense industries are even more likely to impose a tight development schedule. Aircraft and land vehicle development programs are using desktop and HIL simulation to perform design, test, and integration in parallel.



High-burden-rate plant


In many cases, the plant is more expensive than a high fidelity, real-time simulator and therefore has a higher-burden rate. Therefore, it is more economical to develop and test while connected to a HIL simulator than the real plant. For jet engine manufacturers, HIL simulation is a fundamental part of engine development. The development of Full Authority Digital Engine Controllers (FADEC) for aircraft jet engines is an extreme example of a high-burden-rate plant. Each jet engine can cost millions of dollars. In contrast, a HIL simulator designed to test a jet engine manufacturer’s complete line of engines may demand merely a tenth of the cost of a single engine.



Early process human factors development


HIL simulation is a key step in the process of developing human factors, a method of ensuring usability and system consistency using software ergonomics, human-factors research and design. For real-time technology, human-factors development is the task of collecting usability data from man-in-the-loop testing for components that will have a human interface.


An example of usability testing is the development of fly-by-wire flight controls. Fly-by-wire flight controls eliminate the mechanical linkages between the flight controls and the aircraft control surfaces. Sensors communicate the demanded flight response and then apply realistic force feedback to the fly-by-wire controls using motors. The behavior of fly-by-wire flight controls is defined by control algorithms. Changes in algorithm parameters can translate into more or less flight response from a given flight control input. Likewise, changes in the algorithm parameters can also translate into more or less force feedback for a given flight control input. The “correct” parameter values are a subjective measure. Therefore, it is important to get input from numerous man-in-the-loop tests to obtain optimal parameter values.


In the case of fly-by-wire flight controls development, HIL simulation is used to simulate human factors. The flight simulator includes plant simulations of aerodynamics, engine thrust, environmental conditions, flight control dynamics and more. Prototype fly-by-wire flight controls are connected to the simulator and test pilots evaluate flight performance given various algorithm parameters.


The alternative to HIL simulation for human factors and usability development is to place prototype flight controls in early aircraft prototypes and test for usability during flight test. This approach fails when measuring the four conditions listed above.
Cost: A flight test is extremely costly and therefore the goal is to minimize any development occurring with flight test.
Duration: Developing flight controls with flight test will extend the duration of an aircraft development program. Using HIL simulation, the flight controls may be developed well before a real aircraft is available.
Safety: Using flight test for the development of critical components such as flight controls has a major safety implication. Should errors be present in the design of the prototype flight controls, the result could be a crash landing.
Feasibility: It may not be possible to explore certain critical timings (e.g. sequences of user actions with millisecond precision) with real users operating a plant. Likewise for problematical points in parameter space that may not be easily reachable with a real plant but must be tested against the hardware in question.



Use in various disciplines



Automotive systems


In context of automotive applications "Hardware-in-the-loop simulation systems provide such a virtual vehicle for systems validation and verification."[2] Since in-vehicle driving tests for evaluating performance and diagnostic functionalities of Engine Management Systems are often time-consuming, expensive and not reproducible, HIL simulators allow developers to validate new hardware and software automotive solutions, respecting quality requirements and time-to-market restrictions. In a typical HIL Simulator, a dedicated real-time processor executes mathematical models which emulate engine dynamics. In addition, an I/O unit allows the connection of vehicle sensors and actuators (which usually present high degree of non-linearity). Finally, the Electronic Control Unit (ECU) under test is connected to the system and stimulated by a set of vehicle maneuvers executed by the simulator. At this point, HIL simulation also offers a high degree of repeatability during testing phase.


In the literature, several HIL specific applications are reported and simplified HIL simulators were built according to some specific purpose.[1][3][4] When testing a new ECU software release for example, experiments can be performed in open loop and therefore several engine dynamic models are no longer required. The strategy is restricted to the analysis of ECU outputs when excited by controlled inputs. In this case, a Micro HIL system (MHIL) offers a simpler and more economic solution.[5] Since complexity of models processing is dumped, a full-size HIL system is reduced into a portable device composed of a signal generator, an I/O board, and a console containing the actuators (external loads) to be connected to the ECU.



Radar


HIL simulation for radar systems have evolved from radar-jamming. Digital Radio Frequency Memory (DRFM) systems are typically used to create false targets to confuse the radar in the battlefield, but these same systems can simulate a target in the laboratory. This configuration allows for the testing and evaluation of the radar system, reducing the need for flight trials (for airborne radar systems) and field tests (for search or tracking radars), and can give an early indication to the susceptibility of the radar to electronic warfare (EW) techniques.



Robotics


Techniques for HIL simulation have been recently applied to the automatic generation of complex controllers for robots. A robot uses its own real hardware to extract sensation and actuation data, then uses this data to infer a physical simulation (self-model) containing aspects such as its own morphology as well as characteristics of the environment. Algorithms such as Back-to-Reality[6] (BTR) and Estimation Exploration[7] (EEA) have been proposed in this context.



Power systems


In recent years, HIL for power systems has been used for verifying the stability, operation, and fault tolerance of large-scale electrical grids. Current-generation real-time processing platforms have the capability to model large-scale power systems in real-time. This includes systems with more than 10,000 buses with associated generators, loads, power-factor correction devices, and network interconnections.[8] These types of simulation platforms enable the evaluation and testing of large-scale power systems in a realistic emulated environment. Moreover, HIL for power systems has been used for investigating the integration of distributed resources, next-generation SCADA systems and power management units, and static synchronous compensator devices.[9]



Offshore systems


In offshore and marine engineering, control systems and mechanical structures are generally designed in parallel. Testing the control systems is only possible after integration. As a result, many errors are found that have to be solved during the commissioning, with the risks of personal injuries, damaging equipment and delays. To reduce these errors, HIL simulation is gaining widespread attention.[10] This is reflected by the adoption of HIL simulation in the Det Norske Veritas rules.[11]



References





  1. ^ ab T. Hwang, J. Rohl, K. Park, J. Hwang, K. H. Lee, K. Lee, S.-J. Lee, and Y.-J. Kim, "Development of HIL Systems for active Brake Control
    Systems", SICE-ICASE International Joint Conference, 2006.



  2. ^ S.Raman, N. Sivashankar, W. Milam, W. Stuart, and S. Nabi, "Design and Implementation of HIL Simulators for Powertrain Control System Software Development", Proceedings of the American Control Conference,1999.


  3. ^ A. Cebi, L. Guvenc, M. Demirci, C. Karadeniz, K. Kanar, and E. Guraslan, "A low cost, portable engine electronic control unit hardware-in-the-loop test system", Proceedings of the IEEE International Symposium on Industrial Electronics, 2005.


  4. ^ J. Du, Y. Wang, C. Yang, and H. Wang, "Hardware-in-the-loop simulation approach to testing controller of sequential turbocharging system", Proceedings of the IEEE International Conference on Automation and Logistics, 2007.


  5. ^ A. Palladino, G. Fiengo, F. Giovagnini, and D. Lanzo, "A Micro Hardware-In-the-Loop Test System", IEEE European Control Conference, 2009.


  6. ^ Zagal, J.C., Ruiz-del-Solar, J., Vallejos, P. (2004) Back-to-Reality: Crossing the Reality Gap in Evolutionary Robotics. In IAV 2004: Proceedings 5th IFAC Symposium on Intelligent Autonomous Vehicles, Elsevier Science Publishers B.V.


  7. ^ Bongard, J.C., Lipson, H. (2004) “Once More Unto the Breach: Automated Tuning of Robot Simulation using an Inverse Evolutionary Algorithm”, Proceedings of the Ninth Int. Conference on Artificial Life (ALIFE IX)


  8. ^ "ePHASORsim Real-Time Transient Stability Simulator" (PDF). Retrieved 23 November 2013..mw-parser-output cite.citation{font-style:inherit}.mw-parser-output .citation q{quotes:"""""""'""'"}.mw-parser-output .citation .cs1-lock-free a{background:url("//upload.wikimedia.org/wikipedia/commons/thumb/6/65/Lock-green.svg/9px-Lock-green.svg.png")no-repeat;background-position:right .1em center}.mw-parser-output .citation .cs1-lock-limited a,.mw-parser-output .citation .cs1-lock-registration a{background:url("//upload.wikimedia.org/wikipedia/commons/thumb/d/d6/Lock-gray-alt-2.svg/9px-Lock-gray-alt-2.svg.png")no-repeat;background-position:right .1em center}.mw-parser-output .citation .cs1-lock-subscription a{background:url("//upload.wikimedia.org/wikipedia/commons/thumb/a/aa/Lock-red-alt-2.svg/9px-Lock-red-alt-2.svg.png")no-repeat;background-position:right .1em center}.mw-parser-output .cs1-subscription,.mw-parser-output .cs1-registration{color:#555}.mw-parser-output .cs1-subscription span,.mw-parser-output .cs1-registration span{border-bottom:1px dotted;cursor:help}.mw-parser-output .cs1-ws-icon a{background:url("//upload.wikimedia.org/wikipedia/commons/thumb/4/4c/Wikisource-logo.svg/12px-Wikisource-logo.svg.png")no-repeat;background-position:right .1em center}.mw-parser-output code.cs1-code{color:inherit;background:inherit;border:inherit;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;font-size:100%}.mw-parser-output .cs1-visible-error{font-size:100%}.mw-parser-output .cs1-maint{display:none;color:#33aa33;margin-left:0.3em}.mw-parser-output .cs1-subscription,.mw-parser-output .cs1-registration,.mw-parser-output .cs1-format{font-size:95%}.mw-parser-output .cs1-kern-left,.mw-parser-output .cs1-kern-wl-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right,.mw-parser-output .cs1-kern-wl-right{padding-right:0.2em}


  9. ^ Al-Hammouri, A.T; Nordstrom, L.; Chenine, M.; Vanfretti, L.; Honeth, N.; Leelaruji, R. (22 July 2012). "Virtualization of synchronized phasor measurement units within real-time simulators for smart grid applications". Power and Energy Society General Meeting, 2012 IEEE: 1–7. doi:10.1109/PESGM.2012.6344949.


  10. ^ Johansen, T. A.; Fossen, T. I.; Vik, B. (2005). Hardware-in-the-loop testing of DP systems. DP Conference. Houston.


  11. ^ DNV. Rules for classification of Ships, Part 7 Ch 1 Sec 7 I. Enhanced System Verification - SiO, 2010




External links



  • Introduction to Hardware-in-the-Loop Simulation.



Popular posts from this blog

Lambaréné

維納斯堡 (華盛頓州)

Mononymous person