OPERATIONS STAFFING
The science – and art - of satellite mission operations is now more than 50
years old. As the field enters its second half-century, current practices
represent advances in capability that early mission controllers could never
have imagined, and emerging technologies hold forth the promise of further
re-defining this field. Yet, one constant that remains as valuable today as
in the earliest days of mission operations is the human presence, as
necessary for robotic missions as for human spaceflight. True autonomy in
mission operations remains beyond the reach of current flight experience even
as advances continue to be made in this area. For now and for the foreseeable
future, men and women will continue to define and shape the practice of
satellite mission operations.
This paper expands upon principles originally laid down in 2003, which
focused primarily on operations staffing for robotic missions. While
retaining that basis, the scope is extended to include additional background
material, as well as the evolving Constellation Program, NASA’s plan to
return to the Moon in response to the President’s Vision for Space
Exploration. That architecture, which includes multiple vehicles, multiple
missions, and multiple crews, all operating simultaneously between Low Earth
Orbit, the Moon, and bases on the Moon, calls for a radical re-assessment of
current staffing processes and practices lest the costs and technical
barriers engendered by our present-day thinking lead to undesirable
consequences. An assessment of staffing considerations for this program
promises to considerably broaden the current understanding of operations
staffing.
FORCE FIELD ANALYSIS
There is a permanent pressure to provide safe and successful operations for
less money. We live in an era in which "low-cost" is essential to survival in
the aerospace industry. In such a climate of cost constraints, the focus has
turned to life-cycle costs, as it should.
Originally, satellite operations were designed with dedicated operators,
engineers, support staff, and managers stationed in dedicated, speciallybuilt control centers, using dedicated, custom-built, expensive one-of-a-kind
equipment. The traditional control room concept originated in the age where
computers were very bulky, power-hungry, and very expensive, and where
networking was - at best - slow, serial, and dependent upon unreliable dialup lines or expensive fixed lines over the public telephone network. The
software was proprietary and expensive to design, operate and maintain. These
centers were staffed 24 hours per day, seven days per week by rotating crews
stationed on-console monitoring telemetry to ensure the health and safety of
the satellites.
While highly successful in terms of managing spacecraft and collecting data,
even up until relatively recently, that paradigm of operations is also
expensive and inefficient. Its viability is fading due to budgetary
reductions, evolving ground system and range architectures, and the increased
number and complexity of missions.
Depending on the level of sophistication of the satellite and/or the ground
system, varying levels of automation have been introduced with largely
positive results. Such an implementation frees the full-time crew from
monitoring telemetry, thereby enabling them to perform more complex tasks,
and typically allows a reduction in the number of hours where an operator is
on console - permitting, for example, a control center to be staffed for 12
hours/day, 8 hours/day, or even only Monday-Friday – with obvious cost
benefits.
But this is a double-edged sword. While cost savings assume a greater
importance in today’s economic situation, lights-out operations must not
significantly degrade the quality of operations just to save money. The
challenge is to find an optimal balance between three warring influences:
budget, skill, and risk.
Satellite operations – and the attendant satellite monitoring systems - are
becoming more complex as technology advances and the scope of mission
objectives increase. The number of telemetry points that need to be monitored
has increased dramatically. While this presents no significant challenge to
even a modest automation approach, it is the control center personnel –
drawing upon their knowledge, insight, and experience – who must recognize
the relationship and inter-connectedness of subsystems, the significance of a
reported violation, and the immediate response to it that must be taken. The
additional telemetry allows the operator to have more insight, but adds an
element of complexity to the system and requires satellite operators to
develop a more in-depth and detailed understanding of the satellite. Such
ability translates to increased ‘required knowledge-base’ sought in
contemporary satellite control center engineers, which increases the costs of
engineering staff.
Over time, enhanced satellite on-board computing capabilities have resulted
in addition of software embedded to enable the day-to-day operations. Older
satellite platforms used to have very little or no on-board software – most
of the operations were mechanical. Now, virtually all operations are software
driven. Again, this facilitates the controllers’ work, but it also increases
the training and skill requirements and hence the costs of operations staff.
The major components of satellite operations costs are those for staff and
the infrastructure (hardware and software) for spacecraft monitoring and
control. Ignoring for purposes of this paper the infrastructure costs, the
costs for typical staff functions and responsibilities can be grouped as
follows:
Function
 Ongoing spacecraft control
 Planning routine maneuvers
 Planning and execution of
anomaly responses and special
campaigns
 Training of newly hired
engineers, analysts, and
controllers
 Training when new operating
hardware/software is installed
Responsibility
 Lower cost controllers
 Higher cost orbital analysts and
engineers
 Higher cost staff
 Lower cost controllers for OJT
 Higher cost staff for background
and perspective
 Higher cost staff
It is clearly desirable, from a cost perspective, to have a satellite design
that facilitates operations and maintenance by lower-cost controllers, with
the involvement of higher-cost analysts and engineers reduced as much as
practicable. However, such an approach is only feasible when routine
operational tasks (in the post L&EO and commissioning phases) are of such a
nature that they can be done without too much knowledge of the satellite and
its payload. However, as noted earlier, this runs contrary to the prevailing
evolving design of satellites and payloads where aggressive mission
requirements often dictate greater complexity.
EXPLORATION OF ISSUES
Through the combination of more capable satellites, advanced ground systems,
and intelligent monitoring systems, an era of “lights-out” operations for
unmanned satellites has begun to emerge over the past decade. During “lightsout” operations, the ground segment is run autonomously during most routine
operations. Members of the satellite control team need to be involved only in
those tasks that are too costly or too risky to automate. The rest of the
time, the team members are on-call in case of anomalies or emergencies. When
the automated ground system detects an anomaly, it immediately alerts the
appropriate on-call team members and provides them with the most current
information so they can assess the potential implications and, through the
use of appropriate technologies (secure remote user access, intelligent
paging systems, wireless connectivity, etc.) to ensure a time-critical
response, start to resolve the anomaly remotely.
A typical NASA mission using an approach similar to that outlined above
generally needs only one operator working a single shift 8 hours/day, 5
days/week. Prior to lights-out automation, a typical satellite operations
center employed 2 - 3 operators per 8-hour shift, 3 shifts/day, and 7
days/week. Thus, it is easy to see that the proper use of automation can
translate into significant savings in operations costs alone.
But these cost savings extract a price in other areas.
The set-up of the reduced size flight operations team works without much
redundancy on the personnel side. While the consequences of this are plain,
there are other – more subtle – issues that should be recognized. For
example, mission knowledge now often resides solely in the person, not also
on paper as was customary in the past. This poses the attendant risk that the
comprehensive documentation of some older missions is not maintained to the
same degree. This gap in institutional knowledge – particularly from
experience gained in pre-launch testing and integration activities – raises
the potential that subsystem linkages and behaviors might be misinterpreted
or not recognized at all which, in the event of an anomaly, could result in
an operations team taking an inappropriate action or failing to take an
appropriate one.
The trend in spacecraft mission operations is to use autonomy to the greatest
extent possible, as it has been shown that increased autonomy results in
reduced operations costs. Balanced against this savings, however, is an
increase in software costs to develop and implement the desired degree of
autonomy. Despite encouraging trends in automated code generation, the cost
of software development is still very high, as software is extremely
personnel intensive to develop.
Given the assumption that mission safety and reliability will not be
compromised by the introduction of autonomy, it is essential that all
software be rigorously developed and validated to minimize risk. An emphasis
on design reviews, documentation, and Independent Validation and Verification
(IV&V) efforts, which are essential elements of a highly reliable software
development program, create additional burdens that increase the software
development cost.
Consequently, there are practical limits to the application of autonomy to
spacecraft mission operations. As staffing levels continue to be reduced, it
becomes increasingly difficult to eliminate more operators without increasing
risk. Offsetting this risk with autonomy software requires an increasingly
intensive design and test program. At some level, it becomes more costly to
develop a fully robust autonomy capability than it is to use a small
operations team augmented by selected automation capabilities. The goal is to
find the point where the sum of staffing costs and software development costs
is minimized.
Furthermore, an over-dependence on autonomy can ultimately result in a lack
of operator preparedness in the event of a spacecraft emergency. The
operator's situational awareness and familiarity with the spacecraft and its
subsystems’ behaviors must be maintained; indeed, it can be argued that the
implementation of automation requires greater diligence, as it is so easy to
fall into the trap of trusting the software to always do the right thing. It
is imperative that the operators remain close enough to the operation of the
spacecraft that they can respond in a timely and appropriate manner when a
spacecraft contingency or emergency arises. Ultimately, the assessment of a
situation remains in the hands of the human operator, whose familiarity – or
lack thereof – with current on-orbit conditions, expected and telemetered
behaviors, and available options may determine success or failure at that
moment.
CONSTELLATION PROGRAM CONSIDERATIONS
[THIS SECTION WILL NEED MORE DETAILED INPUT FROM THE GROUP.]
Constellation has operational needs that are not addressed by automation as
implemented in support of unmanned space missions. Current development
efforts are not focused on, and in some cases not applicable to,
Constellation needs. That approach is not scalable to support the
Constellation architecture for space exploration, which includes multiple
vehicles, multiple missions, and multiple crews, all operating simultaneously
between Low Earth Orbit (LEO), the Moon, and bases on the Moon. These
elements will require a suite of core, adjustable mission operations
technologies that work together to provide a seamless electronic process that
cross mission and vehicle lines, and use identical tools and processes.
Otherwise, the consequences will be high costs for mission operations due to
proliferation of disparate tools and person-intensive operations practices,
high barriers to automation due to lack of tool interoperability, and high
costs to retire safety concerns as the tools evolve in response to changing
mission needs.
1.0 Operations Staffing Best Practices
Operational staffing is dependent on many variables, including (in no
particular order of importance):
- The available skill set of personnel
- The available budget
- The complexity imposed by the spacecraft design, ground system design,
and other mission requirements (e.g., maneuvers, onboard
reconfigurations, etc.)
- Any required support of interactive payload operations
- The degree of automation that has evolved
-
The number of spacecraft supported by a single control center
Any network elements beyond the control center that are managed by the
team
Any support functions (e.g., data processing, orbit determination,
etc.) performed by the team within the control center.
Once upon a time, just one shift of an operations team might have been
comprised of 5-7 (or even more) personnel, and there would have been shifts
scheduled to provide 24/7/365 support. Added to these numbers would have been
off-line engineers, analysts, technicians, and other supporting personnel.
And that’s not even bothering to mention managers and administrative support!
Such large numbers were necessary due to the complexity of the spacecraft and
ground system, the reliability and maturity of the on-orbit, network, and
ground system elements, basic mission requirements, and a host of other
factors.
But times have changed, technology has advanced, and what once was deemed
risky is now considered routine.
From a functional point of view, we now have Flight Controllers (who
typically manage both on-orbit activities and the ground system) directly
supported by Spacecraft Operations Engineers and Mission Planners/Schedulers.
Ground System Engineers, Flight and Ground Software Engineers,
Systems/Database Administrators, and Flight Dynamics Analysts perform
supporting functions, which may vary in frequency and intensity depending
upon the mission design and requirements. Expanded explanations of the
typical roles and responsibilities of these functions are presented below. It
should be noted that, in some instances, certain of these functions can be
assumed by several or even all members of the operations team – this
illustrates the high skill level demanded of those who now serve in this
capacity.
2.0 Functional Descriptions
2.1 Direct Operations Functions
Flight controllers are responsible for managing the spacecraft commanding and
data capture activities for assigned spacecraft contacts., In this sense,
‘managing’ does not necessarily translate to actually being in the control
center when scheduled contacts occur; rather, it often consists of
fabricating and verifying command loads and the planned schedule of pass
activities in advance, ensuring identified constraints and restrictions are
addressed, and being prepared to respond to anomalous indications or
unforeseen interruptions to the schedule. Under certain conditions (e.g.,
critical maneuvers, anomaly recovery operations, etc.), this responsibility
will dictate real-time interactive command and control of the on-orbit asset
but, under routine conditions, this is often performed by the automated
system (if one exists).
In the past, the responsibilities of flight controllers have sometimes been
divided into three separate categories: spacecraft, payload, and ground;
however, the distinctions between these have eroded so as to be largely
inconsequential. Nevertheless, the following more detailed explanations serve
to illustrate the typical responsibilities of flight controllers today.
Spacecraft Controller: The Spacecraft Controller (SC) directly interacts with
the spacecraft and the ground network during real-time supports, unless
automation is handling these functions. In this real-time capacity, the SC
performs the pre-pass briefing (if required), may need to direct the ground
network’s action such as requesting a sweep of the uplink, uploads commands
to the spacecraft according to contact plans, verifies spacecraft response to
these commands, and participates in the post-pass debrief (if required).
Spacecraft Controllers are responsible for implementing the plans provided by
the Mission Planners and Schedulers, monitoring spacecraft performance,
detecting spacecraft anomalies, notifying the Spacecraft Operations Engineers
of new anomalies, and logging the details of each contact.
At times the SC may implement certain contingency plans and will routinely
implement alternative operations as required. There are certain conditions
and circumstances for which pre-approved actions are identified and, when
appropriate, the SC proceeds to execute these. Typically, however, the SC
does not implement any non-nominal operations without the pre-approval and
guidance of the senior authorized staff.
The SC may assist in anomaly investigation and resolution activities, but
usually does not have the primary responsibility to investigate or resolve
them. The reason for this is because the SC’s prime purpose is to ensure the
safety of the spacecraft, which could be compromised if they are distracted
hunting anomalies. Also, the SC is not an expert on the spacecraft
subsystems, although he/she has a thorough understanding of how the
subsystems work and interact.
Payload Controller: The Payload Controller (PC) is responsible for monitoring
the performance of the payload, including science instruments and any
instrument support subsystems, during real-time operations. The PC also
provides any real-time commanding and control of the payload as needed. For
simple missions, this is usually performed by the Spacecraft Controller. On
more complex missions, real-time payload control is often performed by a
separate payload operations team, which frequently performs this function in
coordination with, but separate from, the flight controllers.
Ground Controller: The Ground Controller (GC) position rarely exists as a
separate entity, even on the largest of operations teams. Nevertheless, the
responsibilities of this position are assumed by the flight controllers,
albeit in a somewhat modified and simplified form. This position is
responsible for ensuring the ground system and, if the MOC has direct control
of the ground antenna station, network assets are able to support a
spacecraft contact and collect, transfer and/or store its data stream. As any
anomalies associated with the end-to-end data flow may occur, the GC is also
responsible for real-time troubleshooting and implementing workaround
procedures to maximize the chances of contact success. Finally, the GC
maintains a log of all activities for each contact and notifies engineering
support personnel of system outages and problems that may require maintenance
or repair.
Mission Planner: The Mission Planner (MP) is responsible for scheduling
contacts on the appropriate communications network (SN, GN, or DSN). The
primary MP functions are to determine the spacecraft’s visibility to network
antennas and schedule contacts and services in accordance with mission
requirements. This will require coordination with the science planners to
select and schedule payload operations and the Project engineering staff to
accommodate any required engineering, maintenance, or configuration changes
that may be necessary. In some instances, other MP functions may include
creating, verifying, and transferring command loads to execute these
operations and contacts; coordinating with the SOE to plan spacecraft
operations and maintenance activities; and building contact plans to guide
the SC through each support. On smaller teams, these functions are typically
performed by the flight controllers.
Data Analyst: On missions that have data processing responsibilities
performed in the control center, the Data Analyst (DA) is responsible for
managing the mission data flow from the time it is received from the ground
station until it is processing and delivered to the customer or archived.
Most data management systems are highly automated, and are capable of
monitoring the data quality, ensuring that any corrupted data packets are
identified for possible retransmission, compiling statistical reports
comparing actual with expected performance, performing initial (Level-0)
processing, archiving the processed data, and delivering the data to
customers in a timely manner. Given this, the DA’s prime responsibility is to
monitor the system operations and to troubleshoot system problems and
anomalous data conditions. As with the Ground Controller, this function has
largely vanished from control centers as a distinct function and is usually
folded into the responsibilities of the flight controllers where data
processing is a requirement.
Orbit Analyst: The Orbit Analyst (OA) performs the flight dynamics function
and is responsible for validating tracking data, creating orbit products,
determining and predicting spacecraft position, formulating maneuver plans,
and verifying the validity of orbital products and processes. Orbit products
are provided to the Mission Planner, the Science Planning Team, and to the
tracking networks.
Spacecraft Operations Engineer: The Spacecraft Operations Engineer (SOE) is
the position with overall responsibility for determining and ensuring
spacecraft safety and mission effectiveness. The primary SOE functions are to
support prelaunch spacecraft functions, supplement other operational
positions as necessary, report spacecraft status to management, and
coordinate with spacecraft component manufactures and integrators as
required. The SOE also has the responsibility for monitoring the health and
status of the payload as it affects the spacecraft bus health and resources,
including such engineering data such as temperatures, voltages and currents.
The SOE is responsible for the trending and analysis of critical spacecraft
SOH parameters and detecting anomalies or potential problems based on both
short- and long-term performance trends. The SOE is responsible for
identifying, documenting, and coordinating the resolution of spacecraft
anomalies.
Payload Analyst: The Payload Analyst (PA) is the position with overall
responsibility for determining and ensuring the payload safety and mission
effectiveness. The PA is the equivalent of the SOE, except with
responsibility for the payload instead of the spacecraft bus. This role is
often provided by a separate payload operations team.
Operations Engineer: The Operations Engineer (OE) is an expert on the
operation of the spacecraft and the overall operations architecture. OEs are
often the technical lead of the operations team, so this position bridges
between operations, engineering support, and management. Ideally, the OE was
involved in the design and development of the operations architecture, and
along with the Spacecraft and Payload Analysts, was involved with the
spacecraft I&T activities. The OE uses the knowledge gained in system
development and I&T to be responsible for developing the operational
procedures and handbooks used by the FOT. The OE assists the Spacecraft and
Payload Analysts in identifying and resolving anomalies and is responsible
for developing, testing and implementing changes in operational procedures,
software, or hardware, including automation.
2.2 Engineering Support Functions
Engineering support staff usually work a standard five-day workweek, but are
on call to respond to system problems that threaten operations. Their primary
function is to ensure that all infrastructure and system components support
the processes put in place by the operations teams to perform readiness and
operations. Some of the positions included in this area are the following:
Ground Systems Engineer: The Ground Systems Engineer (GSE) is responsible for
the overall integrity and performance of the ground system, including the
interfaces between the various subsystems. GSEs monitor the performance of
the ground system, collect and analyze performance metrics, perform ground
system trouble-shooting, design and implement improvements to operations
processes and systems, perform configuration management, and maintain process
documentation and on-line information. They also support the operational
testing of any new systems or software. The GSE is also responsible for
security issues in network design although, with the increasing visibility
associated with evolving Information Technology requirements, these
responsibilities are often shared with or assumed by System Administration
personnel.
Flight Software Engineer: The Flight Software Engineer performs software
troubleshooting, maintenance, and upgrades as required for the flight
software. The work closely with the spacecraft developer engineers, and
follow a rigorous verification and configuration control process before any
changes are made to the onboard software.
Ground Software Engineer: The Ground Software Engineer performs
troubleshooting, maintenance, upgrades, and configuration control for the
ground systems software. The GSE may also be required to interface with
vendors or other software providers.
Systems/Database Administrators (SDA): The Systems/Database Administrators
(SDA) are responsible for all systems management, including Web servers. The
SDAs perform all system backups, monitor system performance, and investigate
all system failures. They are responsible for receiving and installing new
system software patches and set up system login access. They also perform
database administration—performing database updates, backups, and
restorations as needed. The SDA also implements ground system configuration
control.
3.0 Staffing Profiles
[THIS SECTION IS UNTOUCHED FROM THE PRIOR RELEASE OF THIS DOCUMENT. I’M NOT
SURE OF ITS VALUE, AND WELCOME INPUT FROM THE GROUP ON HOW TO STRUCTURE IT.]
The following are provided as examples only. A key way to keep operations
costs down is to reduce staff size to the minimum necessary to meet all
requirements. The primary risk of minimized staff is lack of depth at key
positions, especially for very small teams. One of the mitigation techniques
for this risk is cross training to allow people to back each other up. This
includes selecting operations management and supervisory staff who can occupy
dual positions where they also provide direct operations, at least in a backup capacity. Although they have the technical skills, the managers take care
of personnel issues, ensure the training and proficiency of the people under
them, use metrics to monitor performance, and facilitate process improvement.
Management and supervisory positions are only described in the staffing
profiles section, as they depend on the size of the team.
3.1 Large Dedicated Team
Large, complex missions generally have frequent or lengthy contact with the
spacecraft including frequent real-time commanding to respond to dynamic
operations scenarios. They usually have 24x7 operations support and
relatively complex planning and scheduling processes to support this
complexity. The complexity and dynamic quality of their systems also require
greater engineering support. This relatively large staff will require one or
more managers and an operations supervisor, as described below.
Operations Manager: The Operations Manager (OM) is responsible for all
operational personnel and delegates authority through the operational
supervisors. This manager must be sufficiently familiar with all operations
processes to provide direct supervision of all day-to-day activities,
including real-time command and control, mission planning, data analysis, and
flight dynamics. However, the normal function of the Operations Manager is to
ensure the smooth running and performance of the flight operations teams. The
OM interfaces with people outside operations, such as mission and science
managers.
Engineering Manager: The Engineering Manager (EM) is responsible for the
smooth functioning of the spacecraft and ground segment facilities, including
equipment, operations and software. The EM oversees the technicians,
engineers, and ground station and testbed operators that are required to
perform the maintenance and operations of the space and ground system. The
EM’s duties include generating purchase requests for equipment and repairs,
scheduling and monitoring installations, supervising the maintenance
technicians, ensuring remote site security, and maintaining the overall
facility support environment.
Flight Operations Supervisor: The Flight Operations Supervisor (FOS),
sometimes called a Flight Director, directly supervises all real-time
operations and supporting analysis personnel that are directly concerned with
the health and operation of the spacecraft and ground network. The FOS will
schedule shift operations, and will work closely with operations engineering
to improve the end-to-end operations processes. The flight operations
supervisor is responsible for the training, certification, and recertification of the operations personnel. In addition to his/her primary
function of coordinating all real-time flight operations processes, the FOS
must also be able to assume these real-time and analysis roles as the
situation requires.
The following tables show a staffing profile for a typical large mission.
Table I shows the nominal mission operations staff. During special
circumstances, such as anomaly resolution or initial checkout, additional
support will be needed. Table II shows the typical staff for all the
supporting services to spacecraft operations. These are maintenance, service,
upgrade, and modifications functions necessary for the support of the
spacecraft flight operations. These might be dedicated to a mission, or be
Full Time Equivalents (FTEs) provided by a larger engineering organization
that supports several missions.
Table I – Example Complex Mission Flight Operations Staff
Staff Position
Operations Manager
Flt. Ops. Supervisor
S/C Controller
days off
Payload Controller
days off
Ground Controller
days off
S/C Operations Eng.
analyst
Payload Analyst
Mission Planner
Data Analyst
Orbit Analyst
Operations Engineer
Total
FTE
(Hr/Day)
Comment
1
1
4
8/5
8/5
24/7
Can also do SC & PC jobs
12 hrs on, 12 hrs off, 4 days on, 4
4
24/7
12 hrs on, 12 hrs off, 4 days on, 4
4
24/7
12 hrs on, 12 hrs off, 4 days on, 4
2
8/5
Can also do S/C control and payload
1
2
2
1
2
24
8/5
8/7
8/7
8/5
8/5
Can also do S/C analyst
Mission Planner and Orbit Analyst share
Mission Planner and Orbit Analyst share
Table II – Example Complex Mission Engineering Support Staff
Staff Position
FTE
Engineering Manager
1
Ground Systems Engineer
personnel
Systems Engineer
1
Technician
1
Testbed/Simulator Eng. 2
Flt. S/W Engineer
1
Ground S/W Engineer
2
System/Database Admin. 1
Total
10
(Hr/Day)
Comment
8/5
1
8/5
8/5
8/5
8/7
8/5
8/5
8/5
Fills in for engineering
Electronic/digital and network
Same coverage as the mission planner
Supplemented as needed for upgrades
Supplemented as needed for upgrades
3.2 Medium Complexity Mission with External Support
This case is similar to the first, except that payload support is provided by
a separate organization, and flight and ground sustaining is provided by a
shared pool of engineers, who also support other mission teams. As shown in
Table III, everyone on the operations team reports to an operations manager,
and there are separate leads or supervisors for the people who provide
routine operations and those providing operations engineering of the
spacecraft and ground systems
Table III – Example Medium Complexity Mission Flight Operations Staff
Staff Position
Operations Manager
Flt. Ops. Supervisor
S/C Controller
days off
FTE
1
1
4
(Hr/Day)
Comment
8/5
8/5
24/7
Can also do SC job
12 hrs on, 12 hrs off, 4 days on, 4
Ground Controller
4
days off
Mission Planner
2
Data Analyst
2
Orbit Analyst
1
Lead Operations Engineer
S/C Operations Engineer
payload analyst
GSOE/System Admin
1
Total
19
24/7
12 hrs on, 12 hrs off, 4 days on, 4
8/7
8/7
8/5
1
2
Mission Planner and Orbit Analyst share
8/5
Can also do DA job
Mission Planner and Orbit Analyst share
8/5
8/5
Can also do S/C control and
3.3 Small, Highly Automated Team
As teams become smaller, the operations positions are increasingly
consolidated into a few people, while the functions continue to be performed,
though usually in a less complex way. Furthermore, simpler missions are
easier to automate, leading to still smaller staff. A primary issue for small
teams is retaining knowledge to deal with non-routine circumstances which
require deeper understanding of how the spacecraft and operations processes
work, and which will also be outside the range of automation. Thus small
teams will depend increasingly on operations engineers, the most senior
technical members of a team, to be available to support the mission.
Very small teams will typically be staffed 8x5 or 8x7 only. They will have
two or three operations controllers who can support all aspects of pass
operations, and can also perform routine mission planning and scheduling. If
there are few contacts and/or they are automated, these staff members will
also assist with data management and routine spacecraft trending and
analysis. There needs to be at least 2 OEs, one of whom is the overall
mission lead. If there are only two, there should be a knowledge capture and
training program for building future OEs. This is to protect against the loss
of essential knowledge and skills should one of them leave.
Engineering support is usually obtained from external organizations for small
missions, which do not usually have budget for dedicated engineering support
teams. Spacecraft engineering often is provided by the manufacturer. Ground
systems software sustaining is often contracted to the original vendors. It
is wise, however, to have at least one person, possibly one of the OEs but
often an addition person who is especially focused on ground systems, on the
team who can provide immediate trouble shooting of ground system problems.
3.4 Multi-mission Team
Multi-mission control centers provide small missions a means of retaining
greater depth and specialization that is available to larger missions. They
also provide some protection from the loss of skills with the departure of
key individuals. However, knowledge capture and training is very important
for this type of team. A few differences in staffing from a single mission
center are described. See the section on multi-mission operations for more
detail.
Depending on the number and complexity of the missions supported, the
operations staff profile might be similar to that of a large complex mission:
two or more people on console on shifts covering 24x7 operations, and various
analysts and engineering support on an 8x5 schedule.
The difference from a single large mission comes from the need to allocate
resources among several missions, while retaining attention on the needs of
each mission individually. This can result in a slightly different management
structure. The Operations Manager (OM) will focus on consistent quality of
support across all missions and may devote more attention to interactions
with multiple customers. The Flight Operations Supervisor (FOS) might devote
more attention to schedule conflict resolution. There also should be a lead
for each mission, to assure that each mission’s needs are adequately
addressed, especially when special circumstances require additional support.
This should be one of the OEs, who might be designated the Mission Lead
Engineer (MLE). For complex mipssions, one MLE may be dedicated to a mission.
For less complex missions, a single MLE may be responsible for two or more
missions. For the assigned mission(s), the MLE will provide direction to the
off-line and on-line engineering staff, lead spacecraft anomaly resolution
teams, and be responsible for the integrity of the mission databases. The MLE
will be the primary technical point of contact for the mission customer,
working with the customer in such areas as anomaly resolution, changes in
requirements or operations processes, and conflict resolution decisions.
END