Download 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 Components
FlightGear

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-Hardware
Even though the Suzaku SZ130 has a relatively complete set of peripherals, there are
some components that need to be added.

PWM Reader
A 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 4
A 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 Writer
To 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
SDRAM
Memory Controller
Microblaze CPU
FPU
Digital to Analog
Converter
Custom Serial Writer
FCS PWM
Generator
PWM Reader
OPB
FCS Barometric and
Infrared Sensor Input
iLMB
dLMB
BRAM
GPIO Core
EMC
UARTs
Xilinx Spartan 3 FPGA
GPIO Header
Ethernet
Controller
FlightGear:
FDM State, Control
Surface Positions
Simulated IMU to
FCS IMU Port
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 OPB
Source: IBM_OPB SPEC
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
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
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
Digital to Analog Converters
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.
Digital to Analog Converters
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).
AD5678 Input Shift Register
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
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
uClinux
The 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
System Software
Software Timing
ReadPWM
1%

Reading 4 PWM
Channels ~ 35μs

Generating MIDG II
Packets ~ 2138μs

Writing MIDGII Packets
~ 554μs


Generating Static and
Impact pressures
1691μs
WriteM2*
10%
Barometric
29%
GenM2*
36%
FGControls
24%
Generating FG controls
~ 1400μs
Actual measured loop frequency, 166Hz (Goal of 50Hz)
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
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.
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.
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.
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.
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.
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.
(1)
where:
qc = impact pressure
Psl = standard pressure at sea level
asl is the standard speed of sound at 15 °C
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.
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.
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)
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.
User Interface

HTML based
interface

Runs on HILS board
using thttpd

Uses Common
Gateway Interface
(CGI) to generate
configuration files
Demonstration Video