1 / 40

Hardware In the Loop Simulator

Hardware In the Loop Simulator. Jose E. Ortiz Virginia Commonwealth University. Agenda. Introduction System Overview Components of the HILS Hardware Software Simulation of Sensor Complement User Interface Demonstration Video. What is a HILS?.

reece
Download Presentation

Hardware In the Loop Simulator

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Hardware In the Loop Simulator Jose E. Ortiz Virginia Commonwealth University

  2. Agenda • Introduction • System Overview • Components of the HILS • Hardware • Software • Simulation of Sensor Complement • User Interface • Demonstration Video

  3. What is a HILS? • A HILS is a device that fools an embedded system into ‘thinking’ that it is operating with real-world inputs and outputs. • Operates in real-time on the actual embedded system hardware. • Inputs to the HILS are mirrors of the embedded system’s outputs • Outputs are mirrors of the embedded system’s inputs. • In this case, we are fooling the VCU Flight Control System into believing it is flying an airplane.

  4. Why develop a HILS? • The VCU UAV is a unique system that is difficult to test. • There are no off-the-self systems that match the requirements of our system • It allows for faster testing and development of new control algorithms. • Testing is done using REAL hardware. • It is an expensive and fragile system. Anything that can be done to reduce loss rates is good.

  5. Primary Objective Design and implement a HILS system that: • Tests the FCS embedded hardware and software • Reuse as much hardware as possible • Flexible sensor simulation • MIDG II, static and differential pressure sensors • Simulates fixed wing aircraft • Has a simple UI • Operates at a minimum of 50Hz

  6. VCU FCS System Overview

  7. Hardware In the Loop Simulator

  8. HILS ComponentsFlightGear • Free flight simulator • Open source • Flight Dynamics Model • JSBSim generic 6DoF simulates motion of flight. • takes control inputs, calculates and sums the forces and moments that result from those control inputs and the environment, and advances the state of the vehicle (velocity, orientation, position, etc.) in discrete time steps. • Internal properties are exposed! • Several communications options (TCP,UDP,serial,etc) allows FlightGear to communicate with other software.

  9. HILS Baseboard • Interface between Suzaku FPGA board, FlightGear, and the flight control system • Contains: • 4 x RS232 ports • 4 x 16 bit DACs • 4 x 12 bit DACs • 16 x buffered PWM inputs • 16 x GPIO pins • Power supplies for various components

  10. HILS Baseboard • Designed using Mentor Graphics PADS Logic and PADS Layout/Router • Fabricated by Advanced Circuits using their $33 student special

  11. Suzaku SZ130 (Atmark Techno) Standard Features • FPGA Xilinx Spartan-3E XC3S1200 FG320 • MicroBlaze Soft Processor • Crystal Oscillator 3.6864MHz (frequency multiplied by FPGA’s internal DCM) • BRAM 504Kbits • SDRAM 16Mbyte × 2 • SPI Flash 8Mbyte • Configuration Stored in SPI Flash • JTAG One port (FPGA) • SPI Flash Write Dedicated pin • Ethernet 10Base-T/100Base-Tx • Serial UART 115.2kbps • Timer 2ch (1ch is used by OS) • Free I/O Pin 86 pin • Reset Function - Software Reset • Power Supply Power supply: 3.3V±3% • Consumption current: 350mA typical (when processor is active)

  12. Suzaku SZ130 Additional Soft-Hardware Even though the Suzaku SZ130 has a relatively complete set of peripherals, there are some components that need to be added. • PWM ReaderA pulse width modulation decoder IP core was added to the project. The PWM reader core is configured to read 8 PWM inputs. Reading the PWM value is simply done by reading a memory location. This can be done because the PWM reader is attached to the OPB bus as a memory mapped device. Typical servo pulses range from 1000 to 2000 microseconds. The PWM reader IP core used is the same core that is used in the flight control system. • UART-lite x 4A UART Lite is an IP core from XILIX for the On-chip Peripherals Bus. The UART Lite is a full duplex with 16 byte transmit and 16 byte receive FIFOs. The baud rate and parity are configurable but cannot be changed after synthesis. This allows for creating UART cores that use less FPGA resources. Four additional UART Lites were added to support simulated sensors that use RS232 serial communications. • Custom Serial WriterTo communicate with the DAC a custom Serial Writer IP core was created. This is a simple core that is interfaced using the OPB. A value is clocked to the DAC once it is written to the Serial Writer’s memory mapped register. A synchronization pulse is generated and the 32-bit command sequence is clocked out on the next 32 clock cycles. If the memory mapped register is read, the serial writer will return a non-zero value, indicating that it is currently busy. The Serial Writer is able to operate using the system clock or the clock rate can be divided to accommodate slower serial devices.

  13. HILS Block Diagram

  14. Aside: On-chip Peripherals Bus • The OPB was developed by IBM as part of their CoreConnect architecture. • Designed for integrating on-chip cores. • Can use 32 or 64 bit addreses and data. • Xilinx only implements 32-bit address and data. • Masters can initiate a transaction. • Slaves respond to requests from masters. • Peripherals are typically set up as slaves. • The OPB Arbiter decides which master gains control of the bus. Physical Implementation of the OPBSource: IBM_OPB SPEC

  15. Aside: On-chip Peripherals Bus Arbitration Signals (partial) Each master connects directly to the arbiter through Mn_request and OPB_MnGrant signals. The arbiter also receives OPB_busLock, OPB_select, and OPB_xferAck to monitor bus activity for arbitration. Mn_request (Master Bus Request) The Mn_request signal is asserted by an OPB master to request control of the bus. OPB_MnGrant The OPB_MnGrant signal is asserted by the OPB Arbiter to grant control of the bus to a master device requesting it. OPB_busLock, Mn_busLock(OPB Bus Arbitration Lock) OPB bus arbitration is “locked” whenever OPB_busLock is active. The OPB arbiter will arbitrate among requesting masters during valid arbitration cycles only when OPB_busLock is inactive. While locked, the OPB Arbiter will continue to grant the bus to the OPB master device asserting the Mn_busLock signal, without regard to the priority of the device or other devices with concurrent requests for the bus. OPB_pendReqn (OPB Pending Master Request) The OPB_pendReqn signal indicates to a master that one, or more, of the other masters attached to the bus is requesting access to the bus to perform transfers. This signal is formed by ORing together all master requests on the bus except a masters own. This signal is used by masters performing long locked transfers to determine whether or not they must relinquish control of the bus. Source: IBM_OPB SPEC

  16. Aside: On-chip Peripherals Bus Bus Signals (partial) OPB_ABus(0:31), Mn_ABus(0:31) (OPB Address Bus) The OPB_ABus is used by bus masters to select a unique OPB slave attached to the OPB. The 32 lines of the address bus form a binary number which represents an address. This address will specify a one to one mapping of device functions, peripheral registers, or storage functions contained within devices which are attached to the bus. OPB_DBus, Mn_DBus, Sln_DBus (OPB Data Bus) The OPB_DBus is used to transfer data between OPB masters and slaves. 32-bit and 64-bit data bus implementations are possible. The 32-bit data bus consists of signals (0:31). Bit 0 is the most significant bit, and bit 31 is the least significant bit. The 64-bit data bus consists of signals (0:63). Data Transfer Signals (partial) Mn_select (OPB Select) The Mn_select is driven by an OPB master in the cycle following the assertion of that master’s OPB_MnGrant signal to assume control of the bus and to indicate that a valid data transfer cycle is in progress. Mn_DBusEn, Sln_DBusEn (Master Data Bus Enable) Mn_DBusEn and Sln_DBusEn signals are used to enable a master or slave device’s data onto the OPB data bus(0:31) during write and read transfers, respectively. The Mn_DBus(0:31) and Sln_DBus(0:31) bus are AND’ed with these signals prior to being OR’ed together with other devices’ data buses to form OPB_DBus(0:31). Source: IBM_OPB SPEC

  17. Aside: OPB IPIF and IPIC • The IP Interface services (IPIF) provides a standardized connection to the OPB. • The IPIF uses the IP Interconnect (IPIC) to connect the user logic to the IPIF services. • The IPIF provides: • Address decoding • Interrupt Management • Software accessible registers • IP reset via sw accessible registers • Module identification register • Read and write FIFOs • Simple DMA capabilities (read and transmit sides) • Scatter-Gather DMA

  18. Aside: Create and Import Peripheral Wizard – User Logic Register -- implement slave model register(s) SLAVE_REG_WRITE_PROC : process( Bus2IP_Clk ) is begin if Bus2IP_Clk'event and Bus2IP_Clk = '1' then if Bus2IP_Reset = '1' then slv_reg0 <= (others => '0'); else case slv_reg_write_select is when "1" => for byte_index in 0 to (C_DWIDTH/8)-1 loop if ( Bus2IP_BE(byte_index) = '1' ) then slv_reg0(byte_index*8 to byte_index*8+7) <= Bus2IP_Data(byte_index*8 to byte_index*8+7); end if; end loop; when others => null; end case; end if; end if; end process SLAVE_REG_WRITE_PROC; -- implement slave model register read mux SLAVE_REG_READ_PROC : process( slv_reg_read_select, slv_reg0 ) is begin case slv_reg_read_select is when "1" => slv_ip2bus_data <= slv_reg0; when others => slv_ip2bus_data <= (others => '0'); end case; end process SLAVE_REG_READ_PROC;

  19. Digital to Analog Converters AD5678-2 This is an octal DAC with four 12 bit DACs and four 16 bit DACs in a single package. What makes this particular DAC desirable is that it contains an on-chip voltage reference and the outputs are buffered. • It is able to operate from a single 2.7 to 5.5V supply. • on chip 2.5V reference with an internal gain of 2. This gives a full scale output of 5V. • The internal reference is off at startup and must be turned on by a software write. • The outputs of all DACs can be updated individually or simultaneously. • 3-wire serial interface that can operate with a clock speed of up to 50MHz. • Resistor-string construction, therefore guaranteed to be monotonic • < 0.5 LSB INL, < 0.25 LSB DNL - 12 Bit < 8.0 LSB INL, < 1.0 LSB DNL - 16 Bit

  20. Digital to Analog Converters AD5678-2Write Sequence The write sequence begins at the falling edge of the /SYNC line. Data from the DIN line is then clocked into the 32 bit shift register. This happens at the falling edge of SCLK. On the 32nd falling edge the complete function is programmed and is executed. The /SYNC line must be high for at least 15ns before a new write sequence can begin. The /SYNC line can idle high but less current is drawn when idled low. The custom Serial Writer IP core is used to clock out the 32-bit command to the DAC.

  21. AD5678 Input Shift Register Digital to Analog Converters AD5678-2Commands Bits 24 to 27 of the input shift register correspond to the command to be executed. Bits 20 to 23 are the address bits for a given DAC channel. Bits 4 to 19 are the 16-bit data word for 16-bit channels. Bits 8 to 19 are the 12-bit data word for 12-bit channels. When sending the Setup Iref command, DB0 is used to turn on/off the internal reference(1-on, 0-off). CMD Description ---------------------------------------------------------- 0000 Write to Input Register n 0001 Update DAC Register n 0010 Write to Input Register n, update all (software LDAC) 0011 Write to and update DAC Channel n 0100 Power down/power up DAC 0101 Load clear code register 0110 Load LDAC register 0111 Reset (power-on reset) 1000 Set up internal REF register 1001 Reserved –––– Reserved 1111 Reserved Addr Channel Selected --------------------- 0000 DAC A (16 bits) 0001 DAC B (16 bits) 0010 DAC C (12 bits) 0011 DAC D (12 bits) 0100 DAC E (12 bits) 0101 DAC F (12 bits) 0110 DAC G (16 bits) 0111 DAC H (16 bits) 1111 All DACs

  22. PWM Buffers 74HC7541 The 74HC7541 is an octal Schmitt trigger non-inverting buffer/line driver with 3 state outputs. At room temperature and Vcc of 4.5V, this buffer has a propagation delay of 14ns for both high to low and low to high transitions. The maximum positive going threshold is 3.15V and the minimum negative-going threshold is 1.35V. The typical hysteresis with these conditions is 0.40V. The Schmitt trigger action transforms slow changing input signals into sharply defined outputs. The Schmitt Trigger also prevents against rapid triggering by noise that may be present on the PWM signals. Schmitt Trigger(inverting) The Schmitt trigger is a comparator application which switches the output negative when the input passes upward through a positive reference voltage. It then uses negative feedback to prevent switching back to the other state until the input passes through a lower threshold voltage, stabilizing the switching against rapid triggering by noise as it passes the trigger point.

  23. Other Components These components where used mainly because they were available in the lab. • MAX3232 The MAX3232 from Texas Instruments consists of two line drivers and two line receivers. It provides an electrical interface between logic level communications controller and a RS232 serial port. It can operate at data signaling rates of up to 250kbits/s. Two of these ICs are used to provide level shifting for four serial ports in the HILS base board. • PTH08080W The PTH08080W is an integrated switching regulator module that can provide up to 2.25 A of current. The output voltage can be set by choosing a single resistor. This reduces the number of components needed on the HILS base board. For this application the output voltage has been set to 3.3V and is used to power the Suzaku FPGA board, level shifters and buffers. • UA78M05 The UA78M05 is a fixed voltage (5V) regulator that can deliver upto 500mA. This is a linear regulator that is used to power the DAC.

  24. Completed HILS Interface

  25. System Software uClinuxThe Suzaku computer board uses the uClinux operating system. This operating system eliminates the dependency on a MMU thereby allowing Linux to run on systems based on processors such as the Motorola 68000 and Xilinx MicroBlaze. Because there is no memory management unit, there is no memory protection or virtual memory. Data and code memory is shared between the parent and child process. HILS Software The hardware in the loop simulator software is a relatively simple single threaded application. It is written in C and linked with uClibc. The application is written in a modular fashion. A module is created for each simulated sensor. This allows for different sensor configurations. Currently, three sensors have been implemented. These are the MIDG II, the MPX5010DP and the MPX5100. These three units are the complete complement of sensors used on most of VCU UAVs. Other sensors such as GPS, compass modules, IR horizon sensors, etc can be added to the HILS software to support different UAV configurations. The HILS application communicates with the FlightGear flight simulator using two UDP sockets. One UDP socket is used to receive the Flight Dynamics Model (FDM) from the flight simulator. The other socket is used to send control positions. These include aileron, elevator, throttle and rudder positions. The flight simulator uses this information to update its FDM which is then fed back into the HILS

  26. System Software

  27. Software Timing • Reading 4 PWM Channels ~ 35μs • Generating MIDG II Packets ~ 2138μs • Writing MIDGII Packets ~ 554μs • Generating Static and Impact pressures 1691μs • Generating FG controls ~ 1400μs Actual measured loop frequency, 166Hz (Goal of 50Hz)

  28. Simulating the Sensor Complement MIDG II Sensor The MIDG II is a small Inertial Navigation System (INS) that incorporates Global Positioning System (GPS). Because of its small size, it is well suited for unmanned vehicle applications. The VCU FCS uses the MIDGII as it's primary instrumentation system, therefore its simulated implantation was completed first. Features • 1.50” x 1.58” x 0.88” • Under 55 grams (1.9 oz.) • 3-Axis Rate Gyro • 3-Axis Accelerometer • 3-Axis Magnetometer • Differential Ready GPS; WAAS/EGNOS compliant • Power In: 10 to 32 VDC, 1.2W maximum • Hardware filters provide vibration immunity • Advanced filter algorithms for exceptional performance • Position, Velocity, and Attitude from Kalman Filter at 50Hz • Serial interface at 115200 kbps

  29. Simulating the Sensor Complement MIDG II Sensor The MIDG II INS provides a standard binary protocol that frames sensor messages. This protocol and sensor messages are simulated by the HILS. The packet frame begins with two sync bytes followed by one byte for a message ID, then another byte for the number of bytes in the message. The message payload follows. The packet frame is terminated with a two byte Fletcher checksum. Not all of the messages that can be provided by the MIDG II are used by the VCU FCS. The FCS listens for the NAV_SENSOR, NAV_PV, and GPS_PV messages. The NAV_SENSOR message provides navigation sensor information, the NAV_PV message provides navigation position and velocity solution, and the GPS_PV provides GPS position and velocity solution. Because the FCS only requires these three messages, these are the only messages that are simulated by the HILS.

  30. Simulating the Sensor Complement MIDG II Sensor NAV_SENSOR Message Angular rates, accelerations, yaw, pitch, and roll can be extracted from the flight dynamics model data attained from FlightGear. These parameters are then scaled to the same units used in the NAV_SENSOR message. The packet is then constructed and transmitted to the FCS using an RS232 serial port.

  31. Simulating the Sensor Complement MIDG II Sensor NAV_PV Message To simulate the NAV_PV message, the three dimensional position and velocities are extracted from the FlightGear flight dynamics model. The position information is formatted as Longitude/Latitude/Altitude (LLA) with the same units used by the MIDG II. Similarly, the velocity information is extracted from the flight dynamics model and formatted to cm/s using the East/North/Up (ENU) convention. The solution status bitfield tells the receiver that the position fields are in the LLA format and that the velocity fields use the ENU convention. The packet is then constructed and transmitted to the FCS using an RS232 serial port.

  32. Simulating the Sensor Complement MIDG II Sensor GPS_PV Message The last message required by the FCS is the GPS position and velocity solution. Again, the position and velocity information is extracted from the flight dynamics model and formatted to the proper units. Using the details bitfield, a 3D fix is indicated with the position information in the LLA format and the velocities use the ENU convention. The packet is then constructed and transmitted to the FCS using an RS232 serial port.

  33. Simulating the Sensor Complement MPX5010DP The MPX5010DP is a piezoresistive transducer constructed using thin film micromachining techniques. It has a maximum pressure differential of 75kPa. This sensor is used to measure the airspeed of the aircraft. From the FlightGear flight dynamics model we can extract the calibrated air speed (CAS). The CAS can be used to determine the impact pressure because it is defined as a function of only the impact pressure when a standardized value for the speed of sound is used.

  34. Simulating the Sensor Complement MPX5010DP The formula below defines the calibrated airspeed. We can solve this for the impact pressure as a function of the CAS. Unfortunately, the function is computationally expensive and is not well suited for the HILS hardware. where: qc = impact pressure Psl = standard pressure at sea level asl is the standard speed of sound at 15 °C (1)

  35. Simulating the Sensor Complement MPX5010DP Rather than applying the formula directly, a polynomial approximation can be used. Using (1) we can find a set of impact pressures as a function of the CAS in the range that VCU UAVs fly. This is typically 30 to 200 knots. A very good fit for the impact pressure as a function of CAS is found: qc = 0.1694(CAS)^2 - 0.8223(CAS) + 13.681 Finally, the transfer function of the differential pressure transducer can be used to generate a voltage output. Vout = Vs (0.000009 qc + 0.04)This output voltage is then output by the HILS digital to analog converter.

  36. Simulating the Sensor Complement MPX5100AP The MPX5010DP is a piezoresistive transducer constructed using thin film micromachining techniques. It has a pressure range of 15kPa to 115kPa. This sensor is used to measure the altitude of the aircraft. From the FlightGear flight dynamics model we can extract the altitude above sea level (ASL). The ASL can be used to determine the static pressure because it is defined as a function of only the static pressure.

  37. Simulating the Sensor Complement MPX5100AP The formula below defines the air pressure at a give altitude above sea level (ASL). Unfortunately, the function is computationally expensive and is not well suited for the HILS hardware. Ps = 101325 [ 1 - 2.2557E-5(ASL) ]^5.25588 (2)

  38. Simulating the Sensor Complement MPX5100AP Rather than applying this formula directly, a linear approximation is used. Using (2) we can find a set of static pressures as a function of the ASL in the range that VCU UAVs fly. This is typically 0 to 2000 meters. A very good fit for the static pressure as a function of ASL is found: Ps = -11.323(ASL) + 101325 Finally, the transfer function of the static pressure transducer can be used to generate a voltage output. Vout = Vs (0.000009 Ps - 0.095)This output voltage is then output by the HILS digital to analog converter.

  39. User Interface • HTML based interface • Runs on HILS board using thttpd • Uses Common Gateway Interface (CGI) to generate configuration files

  40. Demonstration Video

More Related