Real-Time Hardware Simulation with Portable Hardware-in-the-Loop (PHIL-Rebooted)

Real-Time Hardware Simulation with Portable Hardware-in-the-Loop (PHIL-Rebooted)

Benjamin W. KingenRiley S. Waite

Marshall Space Flight Center

August 7, 2015

Reviewed by NASA MentorDaniel Heater

ES52

____________________________________Mentor Signature Here

NASA – Internship Final Report

Real-Time Hardware Simulation with Portable Hardware-in-the-Loop (PHIL-Rebooted)

Benjamin W. Kingen1, Riley S. Waite2

ES52 Summer Interns 2015, Marshall Space Flight Center, Huntsville, AL, 35812

PHIL is a system that allows users to emulate satellite instrumentation data as though the satellite's sensors where in an actual space environment. This data can be given to a satellite in real time on the ground for pre-flight testing. The system is small and portable, robust, user-friendly, and allows for third-party hardware while using open-source software. PHIL is the convenient system for use in both educational and professional environments, being as it is cheap, modular, and easy to use.

Nomenclature

r⃑ = Position vector (m) v⃑ = Velocity vector (m/s)r̂ = Relative position unit vector (m) v̂ = Velocity unit vector (m/s)r = Magnitude of relative positions (m) v = Magnitude of velocity (m/s)F⃑ = Force vector (N) a⃑ = Acceleration vector (m/s2)∆ t = Time step (s) t = Elapsed time (s)m = Mass of first body (kg) M = Mass of second body (kg)E = Total system energy (J) K = Kinetic energy of the system (J)U = Potential energy of the system (J) C r = Coefficient of reflection

φ = Solar flux constant (1360.8 Wm2 ) AS = Sun-facing surface area (m2)

T = Fixed exospheric temperature (K) ρ = Atmospheric density (kg/m3) mm = Effective atmospheric molecular mass (amu) H = Variable scale height (km)F 10.7 = Solar 10.7 cm radio flux (SFU) Ap = Geomagnetic IndexG = Gravitational constant c = Speed of light (299,792,458 m /s)AD = Effective drag area CD = Drag coefficienth = Altitude of satellite (m) N t = Newtons of thrust (N)

1 NASA Summer Intern, ES52, Marshall Space Flight Center, Southeast Missouri State University2 NASA Summer Intern, ES52, Marshall Space Flight Center, Taft College

1 Summer 2015 Session

(6.67 ×10−11 m3

s2 kg)

HIL = Hardware-in-the-LoopPHIL = Portable Hardware-in-the-LoopSRP = Solar Radiation PressureADG = Drag force (air resistance)SPRITE = Small Projects Rapid Integration and Test EnvironmentlibSPRITE = NASA’s SPRITE Lab’s real-time software librarySPICE = JPL’s Navigation and Ancillary Information Facility (NAIF) librarySPICE Kernel = File containing planetary and ephemeris dataARTEMIS = HIL software used for testing NASA’s Space Launch System (SLS)MAESTRO = Artemis interfacing softwarebdStudio = Visualization program used for NASA’s Space Launch System (SLS)ODE = Ordinary Differential Equation


[X ] = State vector [ r⃑v⃑ ] f = Generic function

I. IntroductionPRITE (Small Projects Rapid Integration and Test Environment) is a NASA project focused on creating open source software and easily accessible hardware for real-time, hardware-in-the-loop simulations. The SPRITE

Lab’s first iteration of this idea, called PHIL, was a system created with the intention of providing an affordable, modular environment for space flight testing. It functioned as an AC, compact PCI housing one cubic foot in size. Although the PHIL project accomplished its goals, PHIL was found to be too impractical. Its execution platform was a heavily modified and outdated ARTEMIS, its user interface an old version of MAESTRO, and its visualization software bdStudio, all of which were derived from the SLS’s proprietary HIL software.

S

PHIL-Rebooted, the next iteration of PHIL, was created with the objective of reducing overall cost and open-sourcing the system. The entire system is being developed to run solely as a software package, as opposed to the original PHIL system. Not only is this beneficial in terms of user-friendliness, but it will also dramatically reduce the cost of the system by not requiring the purchase of proprietary hardware. Rather, users will only need an inexpensive, third-party USB-IO interfacing board for their closed-loop simulations, allowing for a variety of boards to be used. PHIL-Rebooted’s new execution platform is libSPRITE, an open source, run-time process manager developed by the SPRITE Lab.

II. MethodologyThe majority of PHIL’s software was written in C++. PHIL-Rebooted’s framework, libSPRITE, consists of Lua-wrapped C++ files, or tasks, which can communicate with one-another through a publication/subscription system. These tasks contain three primary functions: initialize, execute, and terminate.

These tasks’ processes are ran, in order, according to their dependence on one another. First, tasks are initialized. Initialization involves configuring tasks and preparing them for execution. Then, tasks are executed repeatedly until termination. During termination, tasks processes are cleanly and safely ended. This process is handled by a Lua script, which acts as the process manager for libSPRITE.


ExecutePropagation

Real-time visualizationData publication

etc.

TerminateClose file streams

Unload kernel poolFree memory

etc.

InitializeInitialize file outputLoad data kernels

Configure simulationetc.

Figure 1. C++ tasks are registered with Lua executive, where they are initialized, executed, and terminated.


A. InitializationDuring initialization, libSPRITE publication objects are constructed. These objects will later be used for communication between libSPRITE tasks.

The PHIL-Rebooted system implements JPL’s SPICE library for accessing planetary and ephemeris data from SPICE kernels. A SPICE meta-kernel, a collection of SPICE kernels, is loaded to the memory pool for access during the execution loop. These kernels are used throughout the simulation, as they contain planetary and ephemeris data.

Simulation parameters, such as a satellite’s name and mass, are loaded from a configuration file into the program.

Bodies are then initialized into an object vector bodies of class type Body. The structure of class Body is as follows:

Objects to be loaded from SPICE kernels require an IAU_ID. This ID is used to identify and access data within the kernels. Objects that are not loaded from kernels are initialized through user-defined parameters. By default, objects are constructed with the assumption that they are to be loaded from SPICE kernel data.

Once bodies has been populated, the system is defined, by user parameter, for energy calculations. This will later be used to calculate the potential, kinetic, and total energies of the system.

A UDP client is initialized for publication of system data. This socketed data is later used for real-time visualization.

B. ExecutionExecution consists of three main parts: calculation, publication, and advancement. The flow of execution is as follows:

1. CalculationBodies can be organized into one of two categories: user-defined or SPICE-defined. A user-defined body is a body that is constructed with user input parameters. A SPICE-defined body is one that is constructed with data loaded from a SPICE kernel.


Body

Type Name Mass Radius IAU_ID

Determine [X ]Next

User-defined

SPICE-defined

Load Kernel Data

Calculate F⃑Net

Check Body Type

Variable DescriptionType Defines body as a satellite or planetary objectName Name of the bodyMass Mass (kg) of the body

Radius Radius (m) of the bodyIAU_ID International Astronomical Union Identification Number (only for SPICE kernel objects)[X ] Body’s Cartesian vector of position ( r⃑ ) and velocity ( v⃑ )

[X ]Next Body’s temporary state vector (stores next state of body)

(2)

(3)

(5)

(6)

(7)

(8)

(9)

(1)

(4)


Per user-defined body, the following process occurs:

Force vector F⃑Net is the sum of forces acting on the body. Net force F⃑Net is calculated as follows:

F⃑Net=∑i=0

n

F⃑ i

Currently, there are four force models: gravitational attraction (F⃑Grav), thrust (F⃑Thrust ¿, atmospheric drag (F⃑ ADG), and solar radiation pressure (F⃑SRP).

For low-earth orbits, F⃑Grav excludes higher-order gravity models such as tectonic shift or crust density fluctuation. Two-body gravitational force is calculated as follows:

F⃑2−Body=−GMm

r2 r̂=−GMmr3 r⃑

For PHIL-Rebooted’s purposes, an n-body gravitational model is necessary. The two-body gravitational force equation can be generalized as:

F⃑Grav=−Gm∑i=0

n M i

r i2 r̂ i

With q̂ t as the direction of thrust, thrust force F⃑Thrust is calculated as follows:

F⃑Thrust=N t q̂t

The atmospheric drag model assumes the area perpendicular to direction of motion AD is constant. For low-earth orbits, drag coefficient CD is assumed to be 2. Atmospheric drag force F⃑ ADG is calculated as follows:

T=900+2.5 ( F 10.7−70 )+1.5 Ap

mm=27−0.012(h−200)

H= Tmm

ρ=6×10−10 e−h−175

H

F⃑ ADG=−12

ρ v2 AD CD v̂


(11)

(12)

(13)

(14)

(15)

(16)

(10)

(17)

(18)

(19)


The solar radiation pressure model assumes that a) sun-facing area AS is constant, and b) solar flux constant φ is truly constant. Solar radiation pressure F⃑SRP is calculated as follows:

F⃑SRP=AS (1.0+C r ) φ

mc

With F⃑Net calculated, [ X ]Next can be determined for user-defined bodies.

By default, system simulation starts at time t=0 (corresponding to epoch “1 Jan 2000 12:00:00 TDB” in SPICE). All user-defined bodies’ [ X ]t are advanced to [ X ]t+∆ t (or [ X ]Next) through a Runge-Kutta 4th order ODE solver as follows:

Given the first order differential equation

f ([ X ] , t )=d [X ]dt

=[ v⃑a⃑], where a⃑=F⃑ Net

m

The estimate for [ X ]t+∆ t is given byk 0=∆ tf ([ X ]t , t)

k1=∆ tf ([ X ]t+k0

2,t + ∆ t

2)

k 2=∆ tf ([ X ] t+k1

2, t+ ∆ t

2)

k3=∆ tf ([ X ]t+k 2, t+∆ t)

[ X ]t+∆ t=[ X ]t+k 0

6+

k1

3+

k2

3+

k3

6

Per SPICE-defined body, loaded SPICE kernels are scanned for data pertaining to the body. If no such data exists, an error is thrown. Otherwise, the body’s [ X ]Next is populated with the corresponding kernel [X ]t+∆ t data.

After per-body calculations, system energies are calculated as follows:

Kinetic:

K=12∑i=0

n

mi v i2

Potential:

U=−G ∑i=1 , j=0 ,i ≠ j

i=n, j=i−1 M j mi

r i , jTotal:



E=K+U

2. PublicationlibSPRITE’s data publication and subscription system functions much like that of a periodical’s. Tasks can subscribe to another’s published data. Likewise, tasks can publish data that can be used by any number of tasks.

After calculations, data is published to the libSPRITE framework for real-time visualization and instrumentation emulation tasks to utilize. Because this data is published via UDP socket, simulation data can be visualized through any socket-capable visualizer.

3. AdvancementDuring advancement, all bodies’ [X ] are updated to their [ X ]Next and time t is incremented by ∆ t .

The execution function is ran indefinitely until user termination.

C. TerminationTermination consists of cleanly and safely closing output streams (such as file, UDP socket, and serial streams), unloading SPICE kernels from data pool, and freeing memory. Tasks are terminated in the same order they were initialized so as to prevent interdependency errors.

III. Data and AnalysisSimulated data was compared against three sources for verification: STK plots, SPICE kernel plots, and an ODE45 integration routine.

STK simulated satellite (Earth-centric) plots were simply compared against propagated plots with the same initial conditions. After three satellite orbits, the accumulated error (magnitude of r⃑ difference between the two satellites) fluctuated in a sinusoidal pattern, peaking at a distance of 1500 m.

Simulated data was compared against SPICE plots, in the same way, with two separate cases. First, a user-defined solar system was propagated, then compared against a SPICE-defined one. After one Earth year, the system’s total accumulated error (magnitude of r⃑ difference between the two satellites) was approximately 0.2%.

A MATLAB simulation, utilizing an ODE45 integration routine, was run against PHIL-Rebooted own (RK4). The r⃑ differences were also negligible, accumulating to approximately 0.15% error after 15 orbits. This was indicative of the accuracy discrepancy between PHIL-Rebooted’s Runge-Kutta 4th order ODE solver and a Runge-Kutta DOPRI 45 ODE algorithm.

IV. Future WorkFuture work will focus on increasing the accuracy and user-interactivity of PHIL-Rebooted’s orbital simulation. Currently, users declare simulation parameters through a configuration file pre-execution. Ideally, a user-friendly interface allowing real-time environmental changes and body construction would allow for error injection testing and improved usability. The implementation of attitude calculations and additional force models (e.g., higher-order gravity) will allow for a more accurate simulation. The simulation’s overall flow and efficiency is always evolving, thus, improving these is an ongoing process.


Figure 2 Magnitude of difference in STK r⃑ and PHIL-Rebooted r⃑


AcknowledgmentsAuthors B. Kingen and R. Waite would like to extend their thanks to their mentor D. Heater, for his continuous support and guidance throughout their internships. Additional thanks go to S. Chait and K. Williams for their collaboration and contributions to the PHIL-Rebooted project.

ReferencesCook, D. G. (2001, 5 23). Solar Radiation Pressure Modeling Issues for High Altitude Satellites. Wright-Patterson Air Force

Base, Ohio: Air Force Institute of Technology.Kennewell, J. (1999). Satellite Orbital Decay Calculations. Sydney, Australia: IPS Radio & Space Services.


Real-Time Hardware Simulation with Portable Hardware-in-the-Loop (PHIL-Rebooted)

Engineering

Transcript of Real-Time Hardware Simulation with Portable Hardware-in-the-Loop (PHIL-Rebooted)