# How I solved two customer use cases with Analysis Workbench

By: Kyle Kochel

Since its inception in STK 10, Analysis Workbench (AWB) continues to be one of the most versatile and powerful modules within the STK toolbox. From my perspective as an engineer on AGI’s technical support team, I leverage AWB on a daily basis to help solve our customers’ toughest problems.

Using AWB, you too can can solve your toughest problems by using the following custom AWB components: vector geometry, time, calculation, and spatial analysis.

Take a quick look below at two customer use cases where I relied on AWB to provide a solution!

## Case 1: Dynamic Sensor Field of View (FOV)

One of our customers was looking for a way to model a dynamically changing FOV for a nadir-pointing conical sensor on a satellite. She wanted both the sensor’s conic half-angle and maximum range constraint to vary based on the current angle between the sensor’s boresight and the sun. She also wanted to determine the times when this sensor could see their ground facility.

At the time, STK did not inherently support the modeling of a dynamic FOV.** The workaround was to leverage AWB to create and keep track of the following scalar calculations:

• Varying sun-angle (created an angle between the sensor’s boresight and the sun that STK tracks over time).
• Varying sensor conic half-angle (calculated by using the varying sun-angle above in a custom AWB function).
• Varying sensor max range constraint (calculated by using the varying sun-angle above in a custom AWB function).
• Range between sensor and ground facility (pulled from the dynamic geometry that STK already calculated).
• Elevation angle from sensor to ground facility (pulled from the dynamic geometry that STK already calculated).

I was then able to create conditions in AWB to determine the times when the ground facility was within range of the sensor (varying sensor max range constraint – range between sensor and ground facility > 0) and when the ground facility was within the sensor’s cone (varying sensor conic half angle + elevation angle from sensor to ground > 90).

Finally, I was able to create a custom time interval list to determine all the times when both of these conditions were met. This list of times represented the access times, or the times when the ground facility was both in range and within the sensor cone geometry.

## Case 2: Chain Object “Angle Between” Values > 180°

A customer needed to get the angle between two satellites with the Earth as the center point, and wanted the values reported from 0 deg to 360 deg. Out of the box, STK could get most of the way there by using a chain object to connect the three objects. The objects were added to the chain object in the following order: Satellite1→Earth→Satellite2. The chain object  has a data provider called Angle Between; however, it only reported the angle in the range of -180 deg to +180 deg.

To get the angle from 0 deg to 360 deg, I used AWB. In summary, I used AWB to create a dihedral angle since this angle type can be defined between 0 and 360 deg. The inputs for this angle were a From vector, a To vector, and an About vector. The From and To vectors were simply the Earth→Satellite1 and Earth→Satellite2 vectors.

The About vector needed to be a vector that was normal to the From and To vectors, but that also remained pointing toward the north pole (ICRF Z). To achieve this, I first created a cross product vector between the Earth→Satellite1 and Earth→Satellite2 vectors. This cross product vector pointed correctly for some time but eventually the satellite geometries changed such that the cross product vector pointed toward the south pole instead. To fix this, I created a Scheduled vector in AWB and used that as the About vector. I set the Scheduled vector up such that it was always normal to the Satellite1→Earth→Satellite2 plane and that it pointed toward the north pole. This led to the angle the customer was looking for.