U-2 Discussion / Use of U-2 in scenarios

[TheOttoman]

In doing research on some Desert Shield scenarios that I am working on, I came across a trove of U-2/TR-1 information and I believe that I've uncovered some inconsistencies with the platform. This post is to provide discussion before an actual request for changes to the database. Throughout this post, I will use the term “U-2R” to represent both the TR-1A and U-2R, as the platforms are effectively identical, and that the TR-1A represent the planes that were assigned to the 17th Reconnaissance Wing, headquartered in RAF Alconbury.

The database contains the following platforms:
2153 - TR-1A Dragon Lady (United States - 1984)
1076 - TR-1A Dragon Lady (United States - 1987-1991)
2152 - U-2R (United States - 1968)
817 - U-2R (United States - 1987)
821 - U-2S (United States - 1995)
2919 - U-2S (United States - 2002)
2096 - U-2S (United States - 2005)
2918 - U-2S (United States - 2013)
For the purposes of this discussion, we will not be talking about platform 2152, the U-2R from 1968

GENERAL DATA
All of the data across the different platforms appears to be correct and without issue.
SENSORS / EW
These entries have the potential for the most change due to how the U-2R is configured. Unlike traditional platforms, the individual sensor package is tied to an airframe, meaning that depending on the mission, a sensor is chosen to fulfill a mission requirement, and then that sensor is married to a specific airframe. Due to the limited inventory of sensors, in some cases there is only one or two of a type of sensor, not all airframes have been modified to carry a specific sensor package. For example, airframe #80-1070 may be configured to accept both the ASARS sensor and the IRIS-III imagery sensor, but airframe #80-1071 may be configured to accept only the ASARS sensor, and a third airframe #80-1072 may be configured to only accept HR-329 camera only and no other sensor package. In the real world this airframe and sensor knowledge is/was a deficiency to the USAF, and this knowledge is maintained by Lockheed contractors. That is why Lockheed contractors will often deploy with the U-2. The sensor packages available to the U-2R are as follows:
• SENIOR BOOK A communications intelligence [COMINT] package used between the 1970’s -80’s specifically created to monitor Chinese communications. Range is unknown
• SENIOR GLASS Before 1996/97, the SENIOR SPEAR, and SENIOR RUBY modules were separate and not linked. SENIOR GLASS is the combination of SENIOR SPEAR and SENIOR RUBY packages into a single module (the right and left underwing pods), along with a vertical antenna farm on the belly of the aircraft.
• SENIOR LANCE Goodyear SAR radar mounted in the Q-Bay Payload. The SAR provided resolutions from 5-foot to 1-foot. Mounted on one or two airframes. 1970’s. Never operationally deployed
• SENIOR OPEN a rotating LOROP (LOng-range Oblique Photographic) camera nose system. Repurposed into SENIOR YEAR.
• SENIOR RUBY an electronics intelligence and signals intelligence package in the right underwing pod. This was further integrated into SENIOR GLASS
SENIOR SPAN this is a satellite link mounted on the top of the aircraft in a teardrop shaped dorsal module, and also in the nose cone of the aircraft. After 1996/7 this package was created to remove the need for a SENIOR BLADE / TRAC station. This allows for transmission of SYERS and ASARS data to be transmitted at ranges greater than 220 miles.
• SENIOR SPEAR is a communications intelligence [COMINT] package that monitors battlefield communications. This package is mounted under the wings in the left pods.
SENIOR SPUR a Beyond Line of Sight data link package. Like SENIOR SPAN, this is mounted on the top of the aircraft in a teardrop shaped dorsal module. After 1996/7 this package was created to remove the need for a SENIOR BLADE / TRAC station. This allows for transmission of SYERS and ASARS data to be transmitted at ranges greater than 220 miles. It is believed that this uses a Ku band satellite datalink to disseminate data as a battlefield relay surrogate.
• SENIOR YEAR the full name is SENIOR YEAR Electro-optical Reconnaissance System (SYERS). This is a dual band electro-optical imagery sensor and infrared sensor. The SENIOR YEAR module had the ability to provide near real time imagery to a ground station (SENIOR BLADE) up to a range of 220 mile. If the U-2R moves outside of the 220 mile range of the SENIOR BLADE station, imagery would be stored on the plane until contact was re-established. A hard copy of the imagery would be available within about 20 minutes of reception in the SENIOR BLADE station. SYERS could only operate in Day / Clear Weather. Deployed 1990+
• ASARS-1/2 Advanced Synthetic Aperture Radar System. Unlike SYERS, ASARS could operate in Day/Night/ All Weather conditions. Much like SYERS, it was able to transmit at near real time speed down to an Army Tactical Radar Correlator (TRAC) station. It had a similar range (220 mi) as SYERS. This is the same radar system that was mounted on the SR-71. ASARS-2 was used extensively during Operation Desert Storm (1991). Its capabilities are a similar, though less powerful version of the E-8 J-STARS program.
• ASARS-2A Upgraded synthetic aperture radar system. Entered service 2001
• PLSS Precision Location & Strike System. This is an electronic intelligence [ELINT] package built to locate specific Warsaw Pact radars and missile sites that are threats to the U-2R. Meant to be used with three U-2R aircraft, each plane would fly in a race-track pattern and triangulate emissions from WP radar and missile sites. Program was cancelled in 1987 without deployment.
This list in not inclusive of all of the other packages that can be mounted in the U-2R including various cameras and sensors. For the purposes of Command, the majority of the U-2Rs that can be deployed will be either a form of the SENIOR YEAR, or ASARS/ASARS-2 configuration. Platform #821 (U-2S United States [Air Force], 1995) lists both of these sensors as deployed. With a range of 100nm. Since both the SYERS and ASARS packages reside in the nose payload, it would make sense they cannot both be part of that platform. However, speaking to the uniqueness and “one-off” of the platform the USAF has made an effort to merge both SYERS and ASARS-2A into a single payload. There is visual representation of a single airframe with both SYERS and ASARS-2 *and* a SENIOR SPAN or SENIOR SPUR module all together. Additionally, prior to the deployment of SENIOR SPAN / SENIOR SPUR, real time imagery would only be possible if there was a datalink back to a SENIOR BLADE/TRAC station (< 220 miles). I’m not sure how that could be modeled in Command so that the U-2 flies over an area outside of the 220 mile radius.
MOUNTS / STORES / WEAPONS
According to Janes All The World’s Aircraft 1986-87, maximum range is listed as 2,605nm / 4,830km / 3,000mi
According to Air Force Military Fact Sheet (http://www.af.mil/About-Us/Fact-Sheets/ ... u-2stu-2s/) Range is listed as 6,090nm / km / > 7,000mi. This could be meant for U-2S and not the U-2R
Typical missions lasted 10-12 hours
COMMS/DATALINKS
All entries list a COMMS/DATALINKS package for both AFSATCOM and Skynet SATCOM. I can find no information listing either one of these packages present. Additionally, while AFSATCOM and the U-2R are Strategic Air Command (SAC) platforms, AFSATCOMs primary use is for National Military Command Centers (NMCC and ANMCC) to connect directly to US strategic nuclear forces. It is obvious that the U-2R is not part of the US Strategic Nuclear Forces. Skynet SATCOM is used by the UK. It is not believable that SAC would allow the UK Ministry of Defense (MoD) to have direct communication to a U-2R pilot through encrypted satellite. I would recommend the deletion of both of these packages from all platforms.
All I have been able to find in terms of avionics is HF, UHF, and VHF communications radios, along with INS, Tacan, ILS, autopilot, ADF, air data computer, a compass and an astro-compass (for night flying). All avionics are stored in a detachable nose section.
There are various datalinks including the SENIOR SPUR Link, Interoperable Data Link and the Dual Data Link that need to be added to the database
PROPERTIES
All platforms list Boom Refueling, and while there are a couple of airframes that have been converted to handle Air to Air Boom refueling, these were more experimental and not operational. Boom Refueling should be removed.
Night Navigation and Fuselage Structure should remain in place
PROPULSION
J57-P-37A: Found in U-2A, U-2E
J75-P-13B #1: Found in U-2C, U-2F, TR-1A, TR-1B, and ER-2 airframes
F118-GE-101 #1 Found in U-2S airframes starting 1995. All airframes converted by 1999
All three types of engines are Turbojects and all have a max speed of about 410-430 kts.
FUEL
The U-2R platform does not use the same “Aviation Fuel” as typical aircraft. I am not sure how this can be modeled in Command, nor do I know how difficult it would be to create a new type of fuel type specific to the U-2R.
NOTES
Unlike many of the typical aircraft platforms, the U-2R is considered a “national strategic asset” meaning up until recently (~2001) the platform was not able to provide true “real time” data down to the warfighter. Due to its assignment to SAC instead of the USAF directly, all missions are normally planned in advance and follow specific tracks avoiding all known radars and missiles in the possible flight path. To further illustrate the process of on the use of the U-2 platform consider the following:
After the shoot down of Gary Powers in 1960, a set of procedures were developed on the authorization and use of the U-2 during peacetime. If a theater CINC wanted intelligence gathered from the U-2R he needed to get approval from the National Command Authority (NCA). The theater CINC would direct his request to the Pentagon’s Joint Reconnaissance Center. There, the center would analyze the request to find out if Air Force assets were already covering the target area, and if the request was appropriate for the U-2. If satisfied, the Center would then coordinate with the Defense Intelligence Agency (DIA) to ensure there was no redundant coverage by sources outside of the Air Force. If DIA approved the request, the Joint Reconnaissance Center then took the request through the Chain of Command up through the Joint Chiefs of Staff, the Secretary of Defense and the president’s national security advisor, who has the ability to approve the request in the name of the President. This part of the process takes about two weeks to accomplish. Once NCA approval is secured, the Joint Reconnaissance Center then sent the request to the Strategic Reconnaissance Center at Offutt AFB (SRC). SRC then made evaluations on all threats to the aircraft, coordinated the movement of the aircraft in cases where the target is outside of the bed down range, along with the movement of sensors and staff and equipment, and then scheduled the sortie SRC then sent the sortie to the Wing, where the mission planners prepared the actual flight track and briefed the pilot. If the mission was flown during peacetime, the pilot flew under Peacetime Applications of Reconnaissance Program (PARPRO) rules. PARPRO flights always were in international or friendly airspace. The plane was flown under VFR conditions, performed regular radio checks and avoided all threats. If for any reasons the pilot could not operate under PARPRO rules, the mission was aborted and RTB.
At the conclusion of the mission, any photography would be sent to the theater photography processing element for analysis. If there was none in theater, then it could take up to a week after the mission was flown before the theater commander could receive the photographs he requested, possibly three weeks from his initial request. To help reduce the time to deliver intelligence, commanders opted to forgo cameras and use electro-optical or radar imagery like SENIOR YEAR or ASARS which provided near real time results if ground stations were in place. It is important to note that during the Cold War and after the DESERT STORM era, these ground stations were almost exclusively in the European theater.
Only in cases of active hostilities, like DESERT STORM, does SAC consider transferring operating control of the U-2R to USAF Combat Commanders (CENTAF, PACAF,EURAF, etc.). DESERT STORM showed the potential for the U-2 to be used in tactical theater operations, however the platform still was a strategic asset operating in a semi-tactical capacity. To overcome this, the SENIOR SPEAR and SENIOR SPAN modules were developed to provide OTH datalinks. However it wasn’t until the late 90’s before these projects were fully deployed. It is assumed that the real-time capabilities are relatively new (> 2001) where imagery can be transmitted to any point on the Earth down to the individual war-fighter, or to a fighter pilot’s mission briefing.

[TheOttoman]

I also have a list of all U-2 / TR-1s that were build and what happened to them, if anyone is interested.

[Raptorx7_slith]

Nvm

[stilesw]

TheOttoman,

Great information. If you have no objections, I am going to include your discussion in the Dropbox reference library. I'm also interested your historical list of U-2/TR-1 air frames. If you wish to provide it I shall include it also.

Thanks,

-Wayne Stiles

P.S. As always, any forum member who would like access to the Dropbox library, please PM me with your email address.

[TheOttoman]

deleted

[TheOttoman]

ORIGINAL: stilesw

TheOttoman,

Great information. If you have no objections, I am going to include your discussion in the Dropbox reference library. I'm also interested your historical list of U-2/TR-1 air frames. If you wish to provide it I shall include it also.

Thanks,

-Wayne Stiles

P.S. As always, any forum member who would like access to the Dropbox library, please PM me with your email address.

Actually.. I wrote this up in a Word doc first before posting. Would you rather that instead of this post?

[stilesw]

I copied it into a Word document for inclusion in the library. Attached is the document for your review.

-Wayne

[stilesw]

Great minds!

[Rory Noonan]

Hey TheOttoman,

Thanks for collating this stuff (and also for making the decision to group discussion here and keep the DB request thread a little less cluttered); summarising everything you'd like added to the DB is a great way to go about it because it makes it a lot easier for me to make the changes you want.

Great timing as well, my current 'main' project is wrapping up and I'll be focusing on database updates after that. Looking forward to your summary in the DB thread [:)]

[TheOttoman]

ORIGINAL: apache85

Hey TheOttoman,

Thanks for collating this stuff (and also for making the decision to group discussion here and keep the DB request thread a little less cluttered); summarising everything you'd like added to the DB is a great way to go about it because it makes it a lot easier for me to make the changes you want.

Great timing as well, my current 'main' project is wrapping up and I'll be focusing on database updates after that. Looking forward to your summary in the DB thread [:)]

Well I guess this is as good a place to start, and we can start with a relatively "easy" one (easy in that it can either be a change or it cannot): the fuel.

The U-2 uses Jet Propellant Thermally Stable (JPTS) fuel instead of normal Jet Fuel. This limits the locations where the U-2 can operate from. A real world example of this is DESERT STORM where the U-2s were given a deployment order to Taif, Saudi Arabia. The air base there had no JPTS and the Air Force was forced to airlift fuel from around the world in order to support operations before a fuel line could be established. My first question would be, is JPTS - a fuel used only for the U-2, listed as a fuel type in the database? (I'm assuming that it isn't) If it isn't, would it make sense to create a new fuel type for a single platform (I have no idea what this would do to the schema, and if this is possible)? If a new fuel can't be created, do we just "cheat" and say that fuel isn't a worry - something that I'm not completely opposed to as the U-2 is as noted, a strategic platform, and would have a very low sortie rate in any given scenario? I don't know how amenable the database (or your dev/ops) is to a change like this to support a single platform.

[Rory Noonan]

Fuel is simplified for aircraft in Command. While replenishment-at-sea for ships will require the right fuel (diesel, gas or oil) for the ship that wants to replenish, aircraft all use the Aviation Fuel type. Since fuel tanks on the ground don't actually count towards refueling (same as for ships and submarines; it is assumed that the logistics of getting the right fuel to the right place in the right amount is taken care of), there's not much point in adding a separate type of fuel for the U-2 at the moment.

An analogous case exists with the SR-71 which in reality uses a pretty exotic fuel type and has its own special tankers which carry this fuel. In game it uses the same fuel as any other aircraft, and the specialised tanker is included for scenario designers to use. In game play it would be up to the player to limit themselves to refueling the SR-71 with that particular tanker--or the scenario designer to impose this limitation. This could be considered a compromise but personally I think it strikes the right balance between accessibility and fine detail.

[TheOttoman]

ORIGINAL: apache85

In game play it would be up to the player to limit themselves to refueling the SR-71 with that particular tanker--or the scenario designer to impose this limitation. This could be considered a compromise but personally I think it strikes the right balance between accessibility and fine detail.

I totally grok that.

[TheOttoman]

In regards to datalinks, a topic that I'm fairly ignorant on, so forgive me if I'm wrong in my thinking.

I believe that both AFSATCOM and Skynet SATCOM should be removed from all of the database entries because the purpose of the U-2 runs counter to the capability of AFSATCOM, and is not part of the nationality of Skynet SATCOM (I'm unaware of, and can't find anything ATM that shows countries other than the UK using Skynet). Radio communications are handled as any other type of communication, so I'm going to guess any form of Secure UHF or VHF Radio /Datalink would work. Looking at the ranges of these radios for the E-3B Sentry (#765), a platform that I know the U-2 has communicated with, I would guess the ranges of these radios would be the same at 100nm. That should cover the "how does the plane communicate?" part of the datalink. That does not, however cover data transmitting somewhere else (which would be modeled in Command as a message telling me that the U-2 detected "X", so I can direct another plane or whatever to attack it). In order to do cover this, we would need to add one of at least 8 new datalinks: SENIOR SPAN, SENIOR SPUR, SENIOR YEAR, ASARS-1, ASARS-2, ASARS-2a, Dual Data Link, and Dual Data Link II. All of these datalinks are unique to the U-2 platform and in all cases (all that I can currently find), they transmit to specific ground stations each with a specific receiver. Using the datalinks in Command as I understand it, in order to issue a Tomahawk strike (for example) to a target the U-2 identifies from one of its sensors, the U-2 must use one of the above datalinks to communicate back to a ground station within range, then that ground station needs to have a means to contact a DDG to issue the fire order (the Command user pressing Shift-F1) to the target.

Is that how datalinks work?


If so, I'll add the 8 datalinks; but that also means that a new facility will need to be added for each of those datalinks (or we can cheat and create a "U-2" ground station that has all of the datalinks present).

[Rory Noonan]

In game the communications net is abstracted to a large extent (another accessibility/depth balance); the player essentially has real time communications with all units on his/her side.

Again the scenario editing tools allow the flexibility to allow pretty much any system you'd like: for example in The Silent Service DLC I implemented various permutations of submarine comms modelling VLF, ELF, SATCOM and a bunch of other stuff, including delayed (and sometimes not particularly reliable) passage of info. These are not features that are 'default' within the game, but the tools are there to implement them.

Adding datalinks etc is no big deal; really it only takes a few minutes. The end result for the user though is not going to be anything noticeable. About the only consequence I can think of off the top of my head is that if the aircraft takes damage it will have more comms devices to be disabled/destroyed before it goes 'out of comms' (assuming that feature is enabled in the scenario). You could definitely use Lua as a scenario designer however to, for example:

Check if the U-2 has a particular comms device
Check if the ground station has a particular comms device
If so then pass the data on
Otherwise no data is passed

The caveat is that the U-2 would need to be on a seperate side, or 'out-of-comms' on the same side for this to work.

TL;DR: Adding the datalinks is no problem but it probably won't have much of an effect on gameplay unless you specifically incorporate it into a scenario via Lua

[TheOttoman]

ORIGINAL: apache85

Check if the U-2 has a particular comms device
Check if the ground station has a particular comms device
If so then pass the data on
Otherwise no data is passed

I'm curious how this would be expressed, specifically the third operation. My LUA knowledge is horrible.

[SeaQueen]

The U-2 is one of my favorite aircraft partially because it is very unique. I'm glad you enumerated all the different recce systems available on the U-2. Each U-2 is almost entirely rebuilt after each flight. In the process, they configure the aircraft with at least one of the systems mentioned, if not a few in combination. The result is that they take a very long time to turn around, and any given airframe can look very different from mission to mission, with a completely different assortment of antenna, pods, nose cones and bulges.

The use of the U-2 in a scenario depends a lot on the scope of a scenario. In most scenarios, they're probably mostly just targets to be defended. It is possible, however, to build a whole scenario around the collection of strategic intelligence (e.g. a nuclear test site, chemical weapons production/storage facility, high level C2 bunker, etc. ).

[RockPaperScissors]

Hi all,

For those interested; attached is a nice NASA aeronautics book on the design and development of the U-2 (to add to your trove) ...

Best regards,

RPS

PS. Considering copyright: it's a free download from the NASA.gov ebooks section, but I'm not allowed [:-] to post links yet

[stilesw]

Another nice reference - added to the library. Thanks again.

-Wayne Stiles

[TheOttoman]

ORIGINAL: SeaQueen

The U-2 is one of my favorite aircraft partially because it is very unique. I'm glad you enumerated all the different recce systems available on the U-2. Each U-2 is almost entirely rebuilt after each flight. In the process, they configure the aircraft with at least one of the systems mentioned, if not a few in combination. The result is that they take a very long time to turn around, and any given airframe can look very different from mission to mission, with a completely different assortment of antenna, pods, nose cones and bulges.

The completely modularity / one off builds is what turned me on to the platform. It's staggering at the amount of uniqueness found throughout the fleet, especially during the mid-80's. To be able to manage that effectively, on a global level is insane.


One of the things I found was that the pilots need to take up to two hours prior to the flight to take in essentially pure oxygen, and that after the flight, they're required to be down for 24-48 hours.

[Rory Noonan]

ORIGINAL: TheOttoman

ORIGINAL: apache85

Check if the U-2 has a particular comms device
Check if the ground station has a particular comms device
If so then pass the data on
Otherwise no data is passed

I'm curious how this would be expressed, specifically the third operation. My LUA knowledge is horrible.

Attached is a quick demo scenario; I've written the code so it is relatively easy to read.

local aircraft = ScenEdit_GetUnit({name='U-2S', guid='6efd1bce-1c43-44ea-879b-1689d3c1fc57'}).guid
local hub = ScenEdit_GetUnit({name='Hub Without Comms', guid='8f767665-dfba-457d-83fc-cbe9eadd05d0'}).guid

local function ListComponents(guid)
return ScenEdit_GetUnit({guid=guid}).components
end

local function ListSharedComms(guidUnitA, guidUnitB)
local result = {}
local componentListA, componentListB = ListComponents(guidUnitA), ListComponents(guidUnitB)
for k,v in ipairs (componentListA) do
if v.comp_type == 'CommDevice' then
for key,value in ipairs (componentListB) do
if v.comp_dbid == value.comp_dbid then
table.insert(result,value)
end
end
end
end
return (result)
end

local function UnitsCanCommunicate(guidUnitA, guidUnitB)
local result
local sharedCommsList = ListSharedComms(guidUnitA, guidUnitB)
if sharedCommsList == {} then
result = true
else
result = false
end
print (sharedCommsList)
return result
end

if UnitsCanCommunicate(aircraft, hub) then
local sharedCommsList, sharedCommsString = ListSharedComms(aircraft, hub), nil
for k,v in ipairs (sharedCommsList) do
sharedCommsString = v.comp_name .. "<BR> "
end
ScenEdit_SpecialMessage('playerside','These units can communicate because they have the following common communications system(s):<BR> '..sharedCommsString)
else
ScenEdit_SpecialMessage('playerside','These units cannot communicate because they have no common communications system(s)')
end

You can substitute in any platforms you like for the ones in the example and this script will evaluate whether they have shared comms devices.

You can get more complicated (e.g. check ranges, weather, time of day, grandma's eye colour, whatever you like) but this for most part would be the basic building block of evaluating comms between two platforms.

A use case for this might be a 'unit detected' event; using the UnitsCanCommunicate() function you could evaluate whether comms were suitable to pass the contact along either through a special message, or switching the relevant unit to auto-detect for a few minutes or some other mechanic.

I've included the above code in a .lua file you can open with any text editor (code doesn't display well on the forum, formatting in the file will make it easier to read)