Operations

On the bridge of a starship, the Ops station allowed the Ops officer to manage the allocation of resources (including power) to the various systems, departments, and personnel aboard ship. Since there were so many things going on aboard even a small starship, the conflicting needs for resources had to be resolved quickly to avoid disrupting the conduct of anyone’s duties. At the Ops station, the Ops officer could quickly and easily handle complicated scheduling and resource allocation issues (routine matters are managed automatically by the computer).

Mission Status

This segment describes the current situation aboard the Theurgy.

UNDER CONSTRUCTION

Standard duties

Essentially, the Operations Department monitored and controlled the use of all ship systems not ostensibly involved with propulsion, navigation, or combat. The Operations Officer on the bridge often had to coordinate directly with the Chief Engineer to ensure that all of the ship's systems were maintained at optimal performance. When no engineer was on the bridge of a starship or operations center of a space station, the Operations Officer saw to any engineering matters that might arise.

Although the transporter systems were Engineering Department assets, it was the Operations Department that put them to use. With regards to special environmental conditions required for alien crewmembers or visitors, the Operations Officer had to coordinate with the ship's Chief Medical Officer.

The Ops Department head position was in charge of the recreation areas of the ship or station as well, such as the various lounges, recreation rooms, gymnasiums and holodecks.

Positions

Here were the common positions in the Operations Department:

Operations Roles
Role	Description
Chief Operations Officer	The Chief Operations Officer had the primary responsibility of ensuring that ship functioned, such as the use of the lateral sensor array, do not interfere with one and another. S/he must prioritize resource allocations, so that the most critical activities could have every chance of success. If so required, s/he could curtail shipboard functions if s/he thinks they will interfere with the ship's current mission or routine operations. The Chief Operations Officer oversaw the Operations department, and was a member of the senior staff.
Asst. Chief Operations Officer	The Chief Operations Officer could not man the bridge at all times. Extra personnel were needed to relive and maintain ship operations. The Operations Officers were thus assistants to the Chief, fulfilling his/her duties when required, and assumed the Operations consoles if required at any time. The Assistant Chief Operations Officer was the second-in-command of the Operations Department, and could assume the role of Chief Operations Officer on a temporary or permanent basis if so needed. On the Theurgy, there were two Asst. Chiefs because of the ship's MVAM capability. In the event that the ship had to separate for a longer duration, the Asst. Chief Operations Officers would serve as Chiefs on their own hull sections respectively.
Operations Officer	The Operations Officer reported to the Chief Operations Officer and Asst. Chief Operations Officers.
Software Engineer	A specialized position focusing solely on the the design, development, and maintenance of the ship's computer systems and LCARS software.
Quartermaster (Currently an NPC)	The Quartermaster specialized in distributing supplies and provisions to personnel aboard the vessel. In addition, the Quartermaster controleds all physical assignments to quarters throughout the vessel.
Boatswain (Currently an NPC)	Each vessel and base had one Warrant Officer (or Chief Warrant Officer) who held the position of Boatswain. The Boatswain (pronounced and also written "Bosun" or "Bos'n") trained and supervised personnel (including both the ship's company or base personnel as well as passengers or vessels) in general ship and base operations, repairs, and protocols; maintains duty assignments for all Operations personnel; set the agenda for instruction in general ship and base operations; supervised auxiliary and utility service personnel and daily ship or base maintenance; coordinated all personnel cross-trained in damage control operations and supervised damage control and emergency operations; might assume any Bridge or Operations role as required; and is qualified to temporarily act at Operations if so ordered. The Boatswain reported to the Chief Operations Officer and Asst. Chief Operations Officers.
Transporter Officer	The Transporter Officer was responsible for all transports to and from other ships and any planetary bodies. When transporting was not going on, the Transporter Officer was responsible for keeping the transporters running at peak efficiency.

Computer Maintenance

One of the tasks that Ops officers handled off the bridge was to maintain the computer systems aboard the starship.

Computers controlled virtually every function of a starship in some way. They regulated the power flow in the warp drive system, operated the sensors, and help the Tactical officer accurately fire the weapons. Without a working computer system, a starship virtually shut down. While the Federation had never managed to build a reliable fully sentient computer before Thea (who doesn't have full access to all systems), starship computers contained such sophisticated artificial intelligence subroutines that they sometimes seemed sentient. They could understand, and respond to, ordinary speech, including contextual cues within that speech. Crewmembers interfaced with the computer system via the Library Computer Access and Retrieval System (LCARS), which let them use voice commands and graphic interfaces to access data, modify ship systems, and write programs. The LCARS contained the equivalent of trillions upon trillion of pages of text, and more data is added every stardate.

A ship’s computer monitored everything occurring on that ship, including the location of everyone aboard ship based on their communicator badge (the Tactical officer could track down anyone aboard, even persons not wearing communicators, but this took some time). When emergencies or crises occurred (such as a failure of life support or hull integrity), the computer evaluated the situation and notified the appropriate personnel. However, that was about all the computer can do; it cannot operate the ship for extended periods, or in other than extremely routine circumstances, without crew control.

Unlike Thea, a standard Starfleet computer lacked the judgment, intuition, and emotions which a sentient humanoid possessed and could apply to complex situations. It could only follow the instructions given it by its programming and the crew. For example, unless instructed to do so, the Starfleet computer would not report that a crewmember has left the ship. Starfleet computers used miniature subspace generators to process data at faster than light speeds. They stored information and programs in modules of isolinear optical storage chips. Each module held 144 isolinear chips. Approximately the size of a microscope slide, an isolinear chip held up to 2.15 kiloquads of data. On large starships, a computer core was a cylindrical structure ranging from about 20 to about 100 meters tall and 10-15 meters in diameter which held thousands of modules containing hundreds of thousands of isolinear chips. Rearranging the isolinear chips within a module, or installing new ones with specialized programming, could interfere with, alter, or in some cases enhance computer operation. If the ship had saucer separation or multivector attack mode capabilities, each “piece” of the ship had to have its own core computer

In addition to the computer cores, ships had a network of subprocessors throughout the ship. These subprocessors help to improve the system’s operation by handling some of the computational load. They could also provide some redundancy for the computer cores. If a ship had two or more computer cores, Starfleet protocols required that at least two operated at once—that way, if service to one was somehow interrupted, the other could instantly, and without loss of significant ship functions, pick up the computational load. In addition to the main computer system, several systems aboard a ship had dedicated computer systems. Examples included the navigation computer and tactical computer.

Optical Data Network (ODN)

Data transmission throughout a ship was accomplished by means of an optical data network (ODN), a network of multiplexed optical monocrystal microfibers. Most ships had from three to six redundant ODN trunks linking their computer cores and the various subprocessors and control panels throughout the ship. Damage to the ODN might have hampered the ability of the ship’s computers to operate the ship.

Bio-Neural Computer System

On some of the latest, most advanced ships, the computer core had been augmented with a bio-neural computer system. This system, which included bio-neural gel packs installed throughout the ship, used organic substances which link with standard computers to create a very powerful information storage and processing device. The gel packs contained synthetic neural cells in a gelatinous organic medium. These neural cells replaced the processors and isolinear chips of the standard Starfleet computer. For lengthy computing tasks, the bio-neural computer system reduces the time needed by 10% (round up; the minimum time for any task is one round).

Although faster and more powerful than standard computers, bio-neural computers were vulnerable to viral infections and other attacks to which organic substances are susceptible. Infections could slow the system down, or even destroy it entirely. Unlike standard computers, which required repairs from engineers when they don’t work correctly, bio-neural systems also needed a doctor’s care when they malfunctioned. For example, to treat an infection, the gel packs might be heated to give them a “temperature” which killed off the virus. Standard regulations regarding the number of computer cores per ship and how many must be operational applied to bio-neural computer systems.

Sensor System Maintenance

While Engineering personnel might assist with these systems, Ops personnel still had to handle the software parts of the starship sensors.

Sensors were a starship’s “eyes.” They allowed it to detect not only phenomena visible to humanoid sight, but an enormous number of electromagnetic and physical phenomena which humanoid senses cannot perceive. Every starship had many different types of sensors (Explorers, Scouts, and Research/Laboratory vessels tend to have more or better sensors, for obvious reasons), divided into four types: long-range; lateral (or short-range); navigation; and specialized. Sensors were rated for three characteristics: the range over which they work accurately; their “gain,” or strength and efficiency relative to their power input; and their strength, or ability to overcome interference.

Caveat: Standard Starfleet sensor technology, as extremely sensitive as it was, did not detect some 15,000 substances. The regular sensor settings did not include certain unusual, rare, and/or exotic materials. It excluded these from the standard analysis routines because they occurred so infrequently that it was inefficient to search for them all the time. Crewmembers could re-calibrate sensors to detect many of these substances, but this usually required them to “blind” the sensors to something they normally registered. Detecting the other types of exotic particles required special sensor equipment and/or analysis programming.

Long-Range Sensors

The long-range sensors, located behind the deflector dish, included narrow- and wide-angle active electromagnetic scanners, a parametric subspace field stress sensor, a gravimetric distortion scanner, an electromagnetic flux sensor, a lifeform analysis instrument cluster, a passive neutrino imaging scanner, a thermal imaging array, and a gamma-ray telescope. Long-range sensors usually involved active scanning. They worked better at high resolution, but this limited their range to five light-years. Their maximum range (at medium-to-low resolution) was typically in the 14-17 light-year range. The arc of detection was usually about 45 degrees in front of the ship, though this narrowed slightly at longer ranges.

Lateral Sensors

Lateral sensors, so called because their sensor pallets were usually located along the edges or sides of various parts of a starship, were shortrange systems which could detect a wide range of phenomena from any direction around the ship. The individual sensor pallets were located all over the ship’s hull to maximize signal gain and system flexibility, and to provide redundancy in case some pallets were damaged. On most starships standard Starfleet sensor packages occupied the majority of a ship’s lateral sensor pallets, but the remainder were open for mission-specific sensor packages. The standard Starfleet science sensor array consisted of six pallets, each containing one to six specific sensory devices.

Lateral sensors were both active and passive. Among their many uses, they were employed extensively in combat situations to monitor enemy movement and activities. Their maximum active range was approximately one light-year.

Nav Sensors

Navigational sensors, which helped the helsman steer the ship in the proper direction and avoid space debris, included a quasar telescope, passive subspace multibeacon receivers, stellar graviton detectors, a Federation Timebase Beacon receiver, and various IR and UV imagers and trackers. The ship’s guidance and navigation (G&N) relay handled the flow of sensor data and converted it into usable information with three- and four-dimensional flight motion software which fed directly into the flight control system.

Communication System Maintenance

If sensors were a starship’s eyes, its communications systems were its ears and its voice. Through personal communicators, planetary broadcast stations, and the Federation’s subspace relay network, a starship could use its subspace radio and other communications devices to contact just about anyone in the quadrant. Subspace radio waves propagated at Warp 9.9997, far faster than the fastest starship, but not always fast enough to allow instantaneous communication with distant locations. Sometimes communications lagged of hours or days result, but in most situations any lags were minimal. However, subspace radio waves could not travel more than 22.65 light-years without degrading to unacceptable levels. Thus, networks of manned and unmanned subspace relay stations were required for communication across the quadrant. No existing or projected Federation technology could overcome this “97/22” limit (though the Borg, at least, seemed to be able to use interplexing beacons to project messages farther than 22.65 light-years).

Most ships had medium-powered subspace transceivers for ship-to-ground communications, and ultra-high-powered transceivers for ship-to-ship and long-range communications needs. The transceivers were located at various points within the ship to provide maximum coverage. Medium-powered transceivers had a maximum range of about 60,000 kilometers; ultra-highpowered transceivers a maximum range of 22.65 light-years as described above. Many Starfleet communications contained confidential, classified, or secret information which threat species could not be allowed to overhear. To prevent such breaches of security, a secured channel might be used for communicating. A secured channel used Starfleet’s advanced encryption algorithms to prevent outsiders from understanding the transmission.

Some of the latest Starfleet vessels incorporated a system which linked communications with a small holoemitter array. When used to communicate with another, similarly equipped, vessel, a holocommunications system allowed the persons communicating to “see” each other.

In crisis situations, such as when main communications were damaged or invaders had locked out the normal communications system, some ships had an emergency communications system which the crew could access. An emergency communications system was half the strength of the main communications system.

Universal Translator (UT)

Every ship’s computer was equipped with a universal translator. This subroutine analysed spoken or written language, compared it to its database (which held thousands of languages), and in almost all cases made an instant two-way translation — each participant in the conversation heard or read the other person’s speech in their native tongue. However, the use of the UT was obvious; the speech came from it, not the person speaking. If a language was not in the UT’s database, it could analyse the language and usually delivered a reasonable translation after no more than a half hour of exposure (the more speech or writing it has to analyse, the less time translation usually took, though the exotic nature or complexity of some languages required more processing time).

Transporter Operations

Instead of using shuttles and other small craft to travel to and from their ships, Starfleet personnel could take advantage of one of the most miraculous of the Federation’s technological achievements: the transporter. The Transporter Officers, which operated this system, belonged to the Ops department.

Transporters dematerialised a subject or object, transforming it from matter into energy, used a narrow-focus subspace carrier wave to transport the energy to a designated location, then transformed the energy back into the matter which was dematerialised. Thus, a person could transport carrying his equipment without worrying about having a phaser’s atoms mixed in with his, or his hair coming out blonde instead of black, or his tricorder failing to work.

Whenever any person or object was transported, the carrier wave included a transporter ID trace — a computer record of the entire transport process. In the event of an accident, personnel could review the trace to try to find out what happened and, if possible, correct the situation. The transport process took about five seconds when using Federation equipment; other species’ transporters might have worked a little slower or faster. Problems such as interference or equipment malfunction might have slowed the process considerably, or posed a risk to the subject. Operating a transporter for the Ops officer was often a delicate and complex task, and even the lightest interference could render transporting dangerous. Problems could easily result in “losing” a person’s pattern forever or an improper materialization (almost always fatal), or sometimes in even more bizarre fates — individuals duplicated or divided into two separate beings, two persons melded into one, or temporal or dimensional rifts (which caused the subject to end up in a different time or dimension than he transported from), just to name a few horrific examples. Fortunately, such accidents were extraordinarily rare — multiple redundancies and safety procedures ensured that the vast majority of transports were absolutely safe, routine, and uneventful. A transporter would not work through a shield or through a cloak.

Transporter Types & Components

There were three types of transporters. The first, the personnel transporter, was primarily designed to transport humanoids and had a range of up to 40,000 kilometers. The second, the emergency transporter, was used to beam personnel away from the ship in evacuation situations; it cannot beam people into the ship, and only has a 15,000 kilometer range. These were also installed in the latest warp fighter cockpits. Both of these transporters could also be used to transport objects, provided they fit on the transporter pads. The third was the cargo transporter, which was mainly used for cargo and other bulky objects; it also had a range of up to 40,000 kilometers. Cargo transporters only worked at the molecular level, and so could not safely transport living beings (they would die).

Transporters had six primary components: The first being the Transporter Officer, who used the control station to monitor and control the operation of the transporter. Ordinary uses required no tests and are very routine, but in case of problems only one of Starfleet’s highly-trained Transporter Officers could ensure the safety of the transported person. The transporter pad’s molecular imaging scanners analysed the subject down to a quantum (subatomic) level. Other scanners on the ship’s hull located the destination for off-ship transports, or persons who were beaming up to the ship (for the latter, they could, by themselves or in conjunction with other sensors, lock on to a combadge signal, life signs, communication signal, or the like). The energizing and transition coils dematerialised the subject, then materialised him at the destination. The energizing coils generated an Annular Confinement Beam (ACB), which created a spatial matrix within which dematerializasion took place. An additional field held the subject within the ACB, since disruption of the ACB field during dematerialization could create a massive energy discharge (which could kill the subject and sometimes bystanders). A transporter operator could boost or reconfigure the ACB in an attempt to overcome interference or other problems.

The subject’s energy pattern was held by the pattern buffer, a magnetic holding tank, before transport began (all transporters had multiple buffers for safety reasons). This allowed the Doppler compensators to adjust for the relative motion between the ship and the destination. A pattern buffer could safely store a pattern for as long as seven minutes; beyond that, or if all pattern buffers experience a minor failure, the subject might begin to suffer from transporter psychosis, a treatable mental disorder which caused hallucinations and delusions (it usually took several hours to manifest). A highly skilled engineer could preserve a matter stream for a long time by shuttling it from one pattern buffer to another (Chief Engineer Montgomery Scott of the original USS Enterprise kept himself alive for an astonishing 75 years with this trick until the crew of the USS Enterprise-D rescued him).

The transporter biofilters scanned every transported matter stream for the presence of known harmful bacterial and viral agents (and some contraband items). If it found any, and no suspension of the filter is made, the transporter automatically edits them out of the subject’s matter stream. Similarly, most transporters automatically prevented the transport of dangerous items, such as bombs. Transporter Officers could used various protocol, to transport persons onto a ship without their weapons or other accoutrements if desired. The emitter and receiver arrays on the ship’s hull transmitted and received matter streams to and from the ship to the destination. The presence or absence of a transporter pad at the destination or beam-up point did not affect the range of any type of transporter. However, it did make transporting safer and easier.

Fighter Bay Ops

As a specialized division of Ops, the Fighter Bay Ops (FBO) crew spent a whole lot more time with Tactical CONN than the Ops department. They were, however, a ship asset, not a fighter squadron asset. The Tactical CONN department depended on FBO, however, needing the fighters primed and ready to go, and if a pilot would have an issue with the condition of his or her allotted fighter, s/he could take it to the affected FBO crew first. Then, if there was no resolution, s/he would go to the SCO (Squadron Commanding Officer) with the issue. The SCO could first try to talk to the Chief of the Deck about the issue, and if that didn't yield the results needed, the SCO may go to Chief of Operations, and after that, to the First Officer, and lastly the Captain.

However, Tactical CONN officers were responsible to do things in the Fighter Assault Bay too, which involved the upkeep of the fighters. Tasks mandatory before and after flying, and they were required to do these tasks so that FBO could do their jobs - meaning that the Chief of the Deck could make such demands to the pilots, and if they ddin't comply, he went to the SCO, and then to the XO, and lastly the CO.

As for the warp fighters themselves, they were neither Tactical CONN's property nor Fighter Bay Operation's. They were commissioned to a starship or a starbase, and therefore the Commanding Officer of the ship. They were Starfleet's property, where the CO would be responsible for the fighters just as much as the starship and shuttles aboard. Tactical CONN's duty was to fly them, Fighter Bay Operations to make sure they work, just like CONN officers' duty was to fly shuttles, and Ops were to make sure they work.

FBO Organisation

Image: Sten Covington, Former Chief of the Deck.

Fighter Bay Ops considered of a total of 125 personnel, spread across 3 shifts.

Command & Administration

• Chief of Deck Operations (COD): Liam Herrold
• Shift Safety Observer (rotating shift duty among all)
• 6 Spacecraft Inspectors
• 6 Landing Signal Warrants

Maintenance & Operations

• Head of Fighter Propulsion & Asst. COD: Avandar Lok
  • 30 Mechanics
• Head of Weapons Maintenance & Armaments: Sithick
  • 18 Weapons Technicians
  • 12 Ordnancemen
• Head of Avionics, Sensors & Computer Systems: (Nameless NPC)
  • 18 Technicians
• Head of Spaceframe & Structure: (Nameless NPC)
  • 30 Repairmen

Disclaimer Notice

Starfleet Operations Emblem used with permission of Gazomg Art - granted Nov 24, 2016

Some of the texts are edits from LUG sources.