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?

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.

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.

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

VCU FCS System Overview

Hardware In the Loop Simulator

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.

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

HILS Baseboard Designed using Mentor Graphics PADS

Logic and PADS Layout/Router

Fabricated by Advanced Circuits using their $33 student special

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)

Suzaku SZ130

Additional Soft-HardwareEven though the Suzaku SZ130 has a relatively complete set of peripherals, there aresome 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.

HILS Block Diagram

PWM Reader

Custom Serial Writer

Microblaze CPU

UARTs

FPU

Memory Controller

OP

B

EthernetController

Xilinx Spartan 3 FPGA

SDRAM

FlightGear:FDM State, Control Surface Positions

Simulated IMU to FCS IMU Port

FCS PWM Generator

Digital to Analog Converter

FCS Barometric and Infrared Sensor Input

GPIO Core GPIO Header

EMC

BRAMd

LM

B

iLM

B

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


Arbitration Signals (partial)Each master connects directly to the arbiter through Mn_request and OPB_MnGrant signals. The arbiter alsoreceives 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_MnGrantThe 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


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

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

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;

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


AD5678-2 Write 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.


AD5678-2 Commands

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

AD5678 Input Shift Register

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.

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.

Completed HILS Interface

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 SoftwareThe 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

System Software

Barometric29%

FGControls24%

GenM2*36%

WriteM2*10%

ReadPWM1%

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)

Simulating the Sensor ComplementMIDG 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

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.


MIDG II SensorNAV_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.


MIDG II SensorNAV_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.


MIDG II SensorGPS_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.


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.


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)


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.


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.


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)


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.

User Interface

HTML based interface

Runs on HILS board using thttpd

Uses Common Gateway Interface (CGI) to generate configuration files

Demonstration Video

Documents

Hardware In the Loop Simulator