Timothy P. Dever

Glenn Research Center, Cleveland, Ohio

Ryan D. May

Vantage Partners, LLC, Brook Park, Ohio

Paul H. Morris

Ames Research Center, LLC, Moffett Field, California

Autonomous Spacecraft Communication

Interface for Load Planning

NASA/TM—2014-218362

November 2014
NASA STI Program . . . in Profi le

Since its founding, NASA has been dedicated to the 

advancement of aeronautics and space science. The 

NASA Scientifi c and Technical Information (STI) 

program plays a key part in helping NASA maintain 

this important role.

The NASA STI Program operates under the auspices 

of the Agency Chief Information Offi cer. It collects, 

organizes, provides for archiving, and disseminates 

NASA’s STI. The NASA STI program provides access 

to the NASA Aeronautics and Space Database and 

its public interface, the NASA Technical Reports 

Server, thus providing one of the largest collections 

of aeronautical and space science STI in the world. 

Results are published in both non-NASA channels 

and by NASA in the NASA STI Report Series, which 

includes the following report types:

• TECHNICAL PUBLICATION. Reports of 

completed research or a major signifi cant phase 

of research that present the results of NASA 

programs and include extensive data or theoretical 

analysis. Includes compilations of signifi cant 

scientifi c and technical data and information 

deemed to be of continuing reference value. 

NASA counterpart of peer-reviewed formal 

professional papers but has less stringent 

limitations on manuscript length and extent of 

graphic presentations.

• TECHNICAL MEMORANDUM. Scientifi c 

and technical fi ndings that are preliminary or 

of specialized interest, e.g., quick release 

reports, working papers, and bibliographies that 

contain minimal annotation. Does not contain 

extensive analysis.

• CONTRACTOR REPORT. Scientifi c and 

technical fi ndings by NASA-sponsored 

contractors and grantees.

• CONFERENCE PUBLICATION. Collected 

papers from scientifi c and technical 

conferences, symposia, seminars, or other 

meetings sponsored or cosponsored by NASA.

• SPECIAL PUBLICATION. Scientifi c, 

technical, or historical information from 

NASA programs, projects, and missions, often 

concerned with subjects having substantial 

public interest.

• TECHNICAL TRANSLATION. Englishlanguage translations of foreign scientifi c and 

technical material pertinent to NASA’s mission.

Specialized services also include creating custom 

thesauri, building customized databases, organizing 

and publishing research results.

For more information about the NASA STI 

program, see the following:

• Access the NASA STI program home page at 

http://www.sti.nasa.gov

• E-mail your question to help@sti.nasa.gov

• Fax your question to the NASA STI 

Information Desk at 443–757–5803

• Phone the NASA STI Information Desk at

 443–757–5802

• Write to:

 STI Information Desk

NASA Center for AeroSpace Information

 7115 Standard Drive

 Hanover, MD 21076–1320
Timothy P. Dever

Glenn Research Center, Cleveland, Ohio

Ryan D. May

Vantage Partners, LLC, Brook Park, Ohio

Paul H. Morris

Ames Research Center, LLC, Moffett Field, California

Autonomous Spacecraft Communication

Interface for Load Planning

NASA/TM—2014-218362

November 2014

National Aeronautics and

Space Administration

Glenn Research Center

Cleveland, Ohio 44135
Acknowledgments

The authors would like to thank the NASA Advanced Exploration Systems Modular Power Systems Project, the Autonomous 

Mission Operations project, and the Space Technology Mission Directorate’s Autonomous Systems Project for funding this work.

Available from

NASA Center for Aerospace Information

7115 Standard Drive

Hanover, MD 21076–1320

National Technical Information Service

5301 Shawnee Road

Alexandria, VA 22312

Available electronically at http://www.sti.nasa.gov

Level of Review: This material has been technically reviewed by technical management. 
NASA/TM—2014-218362 1 

Autonomous Spacecraft Communication 

Interface for Load Planning 

Timothy P. Dever 

National Aeronautics and Space Administration 

Glenn Research Center 

Cleveland, Ohio 44135 

Ryan D. May 

Vantage Partners, LLC 

Brook Park, Ohio 44142 

Paul H. Morris 

National Aeronautics and Space Administration 

Ames Research Center 

Moffett Field, California 94035 

Abstract 

Ground-based controllers can remain in continuous communication with spacecraft in low Earth orbit 

(LEO) with near-instantaneous communication speeds. This permits near real-time control of all of the 

core spacecraft systems by ground personnel. However, as NASA missions move beyond LEO, light-time 

communication delay issues, such as time lag and low bandwidth, will prohibit this type of operation. As 

missions become more distant, autonomous control of manned spacecraft will be required. The focus of 

this paper is the power subsystem. For present missions, controllers on the ground develop a complete 

schedule of power usage for all spacecraft components. This paper presents work currently underway at 

NASA to develop an architecture for an autonomous spacecraft, and focuses on the development of 

communication between the Mission Manager and the Autonomous Power Controller. These two systems 

must work together in order to plan future load use and respond to unanticipated plan deviations. Using a 

nominal spacecraft architecture and prototype versions of these two key components, a number of 

simulations are run under a variety of operational conditions, enabling development of content and format 

of the messages necessary to achieve the desired goals. The goals include negotiation of a load schedule 

that meets the global requirements (contained in the Mission Manager) and local power system 

requirements (contained in the Autonomous Power Controller), and communication of off-plan 

disturbances that arise while executing a negotiated plan. The message content is developed in two steps: 

first, a set of rapid-prototyping “paper” simulations are preformed; then the resultant optimized messages 

are codified for computer communication for use in automated testing. 

1.0 Introduction 

As manned spacecraft travel further from Earth, light-time communication delays will make the 

present ground-based mission control unworkable (Ref. 1). To enable distant missions, NASA has begun 

investigating architectures that will provide autonomous control of the spacecraft (Refs. 1 and 2). 

Currently, controllers develop a complete schedule for all spacecraft components (e.g., Electric Power 

System (EPS), Thermal Management, Communications, Environmental Control and Life Support 

Systems); much of this schedule is created by humans on the ground running software tools to analyze the 

subsystem for which they are responsible (Refs. 3 to 5). 

For the case of the electric power system onboard the International Space Station, the planning 

process involves teams at three different locations (Ref. 5). In addition to solving the planning problem, 

controllers on the ground respond to disturbances and faults that may occur in each of the subsystems. In 
NASA/TM—2014-218362 2 

order to enable autonomous operation, all of this functionality must be implemented onboard. 

Unfortunately, it is neither realistic nor useful to require that the flight crew gain expert knowledge of all 

vehicle subsystems. Thus, the control software must be capable of responding to these situations through 

an autonomous or semi-autonomous decision-making process. 

This paper presents an early attempt to formalize and automate the processes of planning the power 

system load scheduling, and responding to disturbances in the plan or plan constraints, using on-vehicle 

computation resources. The main focus is on development of a communication scheme between two key 

spacecraft components: the Mission Manager (MM) and the Autonomous Power Controller (APC). 

Section 2.0 provides a high-level overview of the proposed autonomous spacecraft control 

architecture, the MM, the APC, and the test power system. Section 3.0 describes the process used for 

development of the communication format for the messages between the MM and the APC. Conclusions 

are presented in Section 4.0. 

2.0 Autonomous Spacecraft Control Architecture 

This section briefly describes the Autonomous Spacecraft Control Architecture discussed more fully 

in Reference 6. Two key subsystems, the MM and the APC, are also described, as is the power system 

under test. 

A potential autonomous spacecraft controller architecture is shown in Figure 1 (Ref. 6). In this 

architecture, the MM is responsible for the high level control functions (e.g., planning), while each of the 

subsystems features an autonomous controller (e.g., Autonomous Power Controller, Autonomous 

Thermal Controller, etc.) which interfaces with the respective subsystem hardware. As previously 

mentioned, this work focuses on developing the communication protocol between the MM and the APC, 

both highlighted in green. 

Figure 1.—Autonomous spacecraft controller architecture. 

 
NASA/TM—2014-218362 3 

2.1 Mission Manager Overview 

The spacecraft MM is responsible for coordinating the various subsystems, as well as managing crew 

time to achieve mission objectives. From the power system perspective, the most important global issue is 

load scheduling (creating a timeline of when loads are in use and their associated priority). However, 

because the vehicle-level optimal planning problem is highly complex, a key goal of this system is to 

limit the amount of subsystem detail the MM is required to know. Thus the spacecraft’s MM must work 

in concert with the APC (where the EPS subsystem detail is located) to develop a load schedule based on 

mission priorities, as well as inputs that it has received from the other autonomous subsystems. Due to the 

fact that the MM has a global perspective of vehicle status, it is able to diagnose and provide 

recommendations regarding faults that affect more than one subsystem (Ref. 7). 

2.2 Autonomous Power Controller Overview 

While the vehicle MM is responsible for strategic planning and coordination of all subsystems, the 

autonomous subsystem controllers such as the APC are responsible for operating the subsystem in the 

manner most consistent with the strategic plan. The APC directly interfaces with the Electrical Power 

System (EPS) hardware, as shown in Figure 1, and has detailed knowledge of the electrical power system. 

This detailed knowledge (e.g., available power, energy storage capacity, operating modes, etc.) allows the 

APC to work in tandem with the MM to solve the relevant vehicle planning problem (i.e., develop a 

feasible a load schedule). The APC also manages local control issues, and reports them to the spacecraft 

MM. 

2.3 Example Power System 

The communication developed in this paper is not tied to any specific vehicle power system. It can be 

applied to any power system type. Typically, such a power system will contain four main components: 

power generation, energy storage, a switchable network, and electrical loads. 

In order to conduct the load planning exercises performed in this paper, it was necessary to define 

vehicle power system architecture. The selected architecture includes solar arrays for power generation, 

batteries for energy storage and a switchable network architecture as described in Reference 7. Also, a set 

of 30 notional loads was defined, and their corresponding power consumption was arbitrarily constructed. 

An eclipse/insolation period of 30/60 min was assumed. 

One key objective of this type of controller is to minimize lower level knowledge required by higher 

level systems. However, note that some key information must be held common by both the MM and the 

APC. In this case, this common information includes the list of loads, the load numbers, and the power 

usage for each load. 

3.0 Communication Development 

This section includes an overview of the communication required between the MM and the APC, 

describes the rapid-prototype “paper” simulations performed, provides details of the test cases run, and 

provides the resultant automated communications message format. 
NASA/TM—2014-218362 4 

3.1 Communications Overview 

The purpose of this message development exercise is to define a communication protocol between the 

MM and the APC, which can be automated and allows the two subsystems to work in tandem to achieve 

the desired goals. The goals of this communication exchange are to enable the two systems to: 

1. Work together to negotiate a feasible load schedule that maximizes the mission objectives achieved 

by the vehicle. 

2. Communicate, and then adapt to, any unexpected deviation from the agreed-upon plan. 

To achieve the goals above, two separate classes of communication have been defined: Planning 

Communications and Asynchronous Communications. 

Planning Communications are used to negotiate a load schedule. They are always initiated by the 

MM, and are used to negotiate a load schedule which is feasible and with appropriate priority (defined by 

the MM), based on the power system availability (defined by the APC). The negotiated load schedule 

must meet global requirements at the MM level, while utilizing local detailed system information (e.g., 

line capacity, state of charge, network configuration, etc.) at the APC level to ensure that no power 

system constraints are violated. The resulting load schedule lists the state and priority of each load in the 

system at discrete time intervals over a defined planning window. This schedule may then be executed 

upon request by the vehicle MM. 

Asynchronous Communications are used when a disturbance arises while executing a previously 

negotiated plan. They are always initiated by the APC outside of the typical planning cycle. These 

messages may be sent in case of component failures, system failures, or any other unexpected change in a 

system operating state or constraint. For the purposes of this document, only disturbances to the load plan 

and unanticipated changes in power availability are considered; component and system failures will be 

addressed in future work. 

A high-level overview of the tasks which must be accomplished during Planning and Asynchronous 

Communications is listed below. 

3.1.1 Planning Communications Cycle 

1. Initiate Planning: At the initialization of the planning process, the MM informs the APC of the 

proposed planning period start time, end time, and time step. 

2. Define Power Constraints: The APC then uses the above data as well as its knowledge of the system 

status to compute the nominal and peak power availability at each time step of the planning window, 

and the peak energy available during the planning window. The APC sends this information, along 

with any load power constraints, back to the MM. 

3. Define Load Schedule: The MM then uses this power, energy, and constraint information, along with 

crew status and information from other subsystems, to develop a proposed vehicle plan. One 

component of this plan is a schedule of load power utilization and priority, for each load in the 

system, which is then communicated to the APC. 

4. Determine Feasibility: The APC performs power flow calculations and contingency analyses to 

determine the feasibility of the proposed load plan at each time step of the planning window. For any 

point at which the plan is found to be infeasible, the APC will determine which of the load profiles 

are in conflict and inform the MM. The planning process will iterate until the MM and APC have 

converged on a satisfactory plan. 

5. Decision (Re-plan or Implement): Finally, the MM either commands the APC to implement the 

negotiated plan at the appropriate start time, or informs the APC of its intention to develop a new 

plan. The MM can ask the APC to implement any plan, regardless of feasibility; however, if the APC 

is tasked with implementing an infeasible load plan, load will be shed to force the system to remain 

within operational constraints.
NASA/TM—2014-218362 5 

3.1.2 Asynchronous Communications Cycle 

Note that the communication necessary to handle these events is inherently unplanned. 

1. Inform of Disturbance: Upon detection of a disturbance, the APC will determine the impact of the 

disturbance on its capability to operate as specified during the currently executing plan. This 

information, which is key to determining if a replan is necessary in order to maximize the vehicle’s 

mission objectives, is passed to the MM. 

2. Decision (Re-Plan or Implement): The MM then decides whether a replan is necessary. If so, the 

planning process is started via a Planning Communications Cycle, with the disturbance accounted for 

as a new constraint. 

3.2 Paper Simulation 

The initial development of communication messages between the MM and the APC was 

accomplished using “paper simulations.” These paper sims utilized spreadsheets to generate messages, 

and email to transmit them between the MM (being developed at NASA Ames Research Center, in 

California) and the APC (being developed at NASA Glenn Research Center, in Ohio). In this manner, a 

number of complete planning sessions (Planning Communications Cycles) and disturbance identification 

and rectification sessions (Asynchronous Communications Cycles) were completed. This approach was 

taken to accomplish two goals: to accelerate communication message development, and to allow quick 

refinement of the relevant message content. 

At the time of the message format development, only prototype versions of the MM and the APC 

existed. These prototypes performed the relevant functions of the respective subsystems, but they were 

not yet automated—they only worked with a human in the loop. One obvious advantage of the paper sim 

approach was speed: by initiating paper simulations early on, the teams did not have to wait until 

automation of MM and APC functions was complete, thus accelerating development. Additionally, the 

messages developed during the paper sim drove the requirements of the automated software algorithms. 

Since entire Planning and Asynchronous Communication cycles were rapidly completed via the paper 

sims, lessons about which message content is relevant and which is superfluous were quickly learned. Use 

of spreadsheets, with easily variable content and format, along with email and phone communication 

between development teams allowed rapid evolution of message content, allowing messages to quickly be 

reduced to a thorough, yet efficient, format. This refinement allowed many details of the message content 

to be finalized early in the development cycle, where changes and updates are least expensive in terms of 

effort and schedule. 

3.2.1 Test Cases 

Throughout the paper sim, planning simulations were conducted under a variety of test conditions, in 

order to verify that the messages under development contained the necessary format and content to 

achieve the desired goals under any reasonable set of conditions. 

During Planning Communications development, sims were performed under a number of power 

system constraints: with imposed battery state of charge (SOC) limits, solar array (photovoltaic, or PV) 

output limits, PDU current output (single or multiple) limits, battery current limits, and line current limits. 

Disturbances introduced during development of Asynchronous Communications included unexpected 

load operation (loads on longer or shorter than expected, with varied impacts on the existing Plan), loads 

drawing less power than planned, and sources providing less power than planned. 

The details of the paper sim testing conditions are summarized in Table 1. 
NASA/TM—2014-218362 6 

TABLE 1.—PAPER SIM COMMUNICATION TESTING CONDITIONS 

TABLE 2.—DETAILS OF P1 COMMUNICATION 

P1 #12 26ͲMarͲ14

  

start time end time delta T (min)

12:00 10:30 30

3.2.2 Planning Communications Cycle 

During the course of the paper simulations, five messages were developed for a typical planning 

session. These are designated P1 through P5. 

3.2.2.1 Initiate Planning (P1) 

The P1 is initiated by the MM to start the planning process. Along with a header defining the message 

type, simulation number, and date (typical of all paper simulation communications), the P1 specifies the 

planning horizon: start time, end time, and time step (delta T). It is important to note that the delta T used 

in the planning process is dependent upon both vehicle and power system time scales of interest, 

particularly eclipse/insolation periods. Details of the P1 communication are shown in Table 2. 

Planning

Test Implementation Sim Tested Details

1 Battery SOC within limits Sim #1Ͳ13

Constraint captured by peak power availability

& energy availability

2 PV Output < limit Sim #1Ͳ13 Constraint captured by power availability

3 Limit one PDU power Sim #3 Limit PDU 5 to 2kW

4 Limit multiple PDUs Sim #4 PDU 1Ͳ4 limited to 425W switchable global

5 Limit line current Sim #6 Limit line current from SA 1

6 Limit battery current Sim #5

Limit Batteries to 83 A (10kW, down from

133A/32kW).Battery 1 global, battery 2

temporary.

7 Temporary PDU power constraint Sim #4 PDU 7 limited for 1 interval

Asynch

Test Implementation Sim Tested Details

1

Load on for too longͲno impact

in planning period Sim #8

Load 13 on beyond scheduled periodͲshould

have turned off at 4:30

2

Load on for too longͲimpact

during planning period Sim #11

Load 12 remained on beyond scheduled period Ͳ

should have turned off at 2:30

3 Load on for too short Sim #9 Load 5 off 30 mins early

4

Load on for too shortͲadditional

power available significant, thus

opportunity

Sim #13

Loads 12 and 14 turned off early (expected

them to be on until 2:30)

5

Actual load < est loadͲadditional

power available insignificant Sim #10

Load 26 drawing less power than planned

(expected 700W, drawing 550W)

6

PV array output < est outputͲ

requiring replan Sim #12 Output from Solar Array 1 lower than expected
NASA/TM—2014-218362 7 

3.2.2.2 Define Power Constraints (P2) 

The P2 is the APC’s response to a P1 message from the MM. In addition to the header, the P2 

contains nominal and peak power available for each time step in the planning window, as well as peak 

energy available to the MM during the course of the planning window. Also, any known constraints 

(temporary or global) on the system are also communicated. Constraints are formulated as the sum of 

loads must not exceed some power level. All power system constraints considered in the paper 

simulations are able to be constructed in such a manner. Note that this approach requires that both 

systems have common understanding of loads and load IDs. A distinction is made between “local” 

constraints, those active only during some planning intervals, and “global” constraints, those active during 

all intervals in the current planning window. 

Nominal power is the amount of power available given that the storage devices in the system are 

charging at a constant rate for the entire insolation period. During eclipse periods, the nominal power is 

the amount of power that the storage devices can supply to the system for the entirety of the eclipse 

without exceeding state-of-charge requirements. The Peak power considers that all generation devices are 

outputting at maximum for the time period. Thus, imbedded in this number are device power output 

constraints as well as each generator’s time-varying capability. 

If the power utilization (as defined by the load profile) is greater than the nominal power available, 

then the storage devices will be used to meet the excess load requirements. The result of this is that the 

storage cannot be charged and/or will deviate from the nominal state-of-charge range. To allow the MM 

to wisely use this capability, the total energy availability of the storage devices is given by the APC (in 

Watt-hours). The MM is then responsible for tracking the amount of peak power utilized as well as the 

duration used; the sum of the peak energy used for all time periods must be less than the peak energy 

available as provided by the APC. Details of the P2 communication are presented in Table 3. 

3.2.2.3 Define Load Schedule (P3) 

The P3, initiated by the MM in response to the P2, contains the proposed load schedule, developed 

based on the provided power profile. In addition to the header, the message contains a load status and 

priority for every load at each time step in the planning period. 

For this study, all loads are either “off” or “on” (both systems have shared info as to how much power 

each load uses when on and off). Thus, both the state and priority of each load can be encoded in a single 

value, either “off” or a priority number. Here, the lower the priority number, the higher the priority of the 

load. Details of the P3 communication are presented in Table 4. 

TABLE 3.—DETAILS OF P2 COMMUNICATION 

P2 #1226ͲMarͲ2014 

 

time Pnom (W) Ppeak (W) constraints

12:00 6008 45968

12:30 6008 45968

. . . . . . . . . . . .

3:30 6008 45968

4:00 5984 21968 loads 4,8,25,27,29 combined must not

exceed 60W

. . . . . . . . . . . .

5:30 5984 21968 loads 4,8,25,27,29 combined must not

exceed 60W

6:00 6008 45968

. . . . . . . . . . . .

9:30 6008 45968

10:00 5984 21968

peak energy avail

(Wh)

8000

  Global Constraint: Loads 1, 19 and 23

combined must not exceed 360 W
NASA/TM—2014-218362 8 

TABLE 4.—DETAILS OF P3 COMMUNICATION 

P3 #1226ͲMarͲ2014    

     

 12:00:00 AM 12:30:00 AM . . . 10:00:00 AM

load Priority Priority . . . Priority

1 off off . . . off

2 off 12 . . . off

3 off off . . . off

. . . . . . . . . . . . . . .

29 41 41 . . . off

30 off off . . . 22

TABLE 5.—DETAILS OF P4 COMMUNICATION 

P4 #918ͲMarͲ2014 

 

time status

12:00 able to meet

. . . . . .

9:30 Loads 1, 4, and 9 must not

exceed 500W

10:00 able to meet

TABLE 6.—DETAILS OF P5 COMMUNICATION 

P5 #1226ͲMarͲ2014   

"Implement Plan"

3.2.2.4 Determine Feasibility (P4) 

The P4, initiated by the APC in response to the P3, determines feasibility of meeting the proposed 

load schedule. In addition to the header, the P4 contains a status at each time step of the planning period, 

communicating whether or not the power system can meet the load schedule. If the system cannot meet 

the proposed schedule, the message describes the nature of the conflict. Again, any constraint will be 

formulated as the sum of loads must be less than some power level. Details of the P4 communication are 

presented in Table 5. 

3.2.2.5 Re-Plan or Implement (P5) 

The P5 message, initiated by the MM, commands the APC to implement the proposed plan in the event 

that the P4 stated “able to meet’ at all-time steps. Otherwise the MM will rework the schedule, which is 

done by recalculating, then sending out a new P3. Details of the P5 communication are presented in Table 6. 

An “Implement Plan” P5 message concludes a successful planning session. 

3.2.3 Asynchronous Communications Cycle 

Two different asynchronous messages were developed during the course of the paper simulations: the 

A1 and the A2. 

3.2.3.1 Inform of Disturbance (A1) 

The A1 message is initiated by the APC in the event of a disturbance to the power system or a 

deviation in the system that impacts a parameter used during load planning. In addition to the header, it 

contains the time of occurrence, the nature of the disturbance, and the impact on the schedule. Schedule 

impact is described by the time, within the planning window, at which the disturbance will prevent the 

power system from meeting the negotiated schedule. If the disturbance causes no impact to the schedule, 

no time is provided. Details of the A1 communication are presented in Table 7. 
NASA/TM—2014-218362 9 

TABLE 7.—DETAILS OF A1 COMMUNICATION 

A1 #1226ͲMarͲ2014

Time Disturbance Impact

3:05 Output from Solar Array 1 lower

than expected “No impact within planning period" or "Will exceed peakpower allotment by 3:27”

TABLE 8.—DETAILS OF A2 COMMUNICATION 

A2 #1226ͲMarͲ2014

"Replan Required" or "No Action Required"

3.2.3.2 Re-Plan or Implement (A2) 

The A2 message is initiated by the MM in response to an A1. In addition to the header, the A2 

communicates response to the disturbance: “No Action Required”, or “Replan Required”. Details of the 

A2 communication are presented in Table 8. 

3.3 Automated Communications Format 

The final step in the development of the communication format was to convert each message into a 

computer readable format, to enable these messages to be sent and processed by automated software. 

Since we were not overly concerned with message bandwidth at this early development stage, a bit-level 

encoding was not necessary. Additionally, coding the messages as character arrays allows them to be 

processed by software, while maintaining human readability, which will be helpful during testing. 

The protocol over which the messages are to be sent is not particularly important at this time, and thus 

TCP sockets are used. Whitespace and line breaks included in the messages shown below are simply for 

human readability and are stripped from both incoming and outgoing messages. 

Note that the messages use a 24 hr clock; thus use leading zero if applicable (hh:mm). Also, text is 

not case-sensitive for the receiver, but is standardized for the automated sender: capitalize first word only. 

Pseudo-code describing the decision logic for message handling, from the MM and the APC 

perspective, is provided below. 

 1. MM Message Handling Pseudo-code: 

If START 

 then send P1 message 

 else if receive P2 message 

 then send P3 message 

 else if receive P4 message 

 then if P4 message has no violations 

 then send P5 message (Implement) 

 else resend P3 with the new constraints from P4 taken into account 

 2. APC Message Handling Pseudo-code: 

If receive P1 message 

 then send P2 message 

 else if receive P3 message 

 then send P4 message 

 else if receive P5 message 

 then Implement 

Details of the developed Automated Communications Format messages, for the Planning and 

Asynchronous Communications, are included in the following sections. 
NASA/TM—2014-218362 10 

3.3.1 Planning Communications Cycle 

Automated formats for the five messages comprising a typical Planning Communications session are 

described below. 

3.3.1.1 Initiate Planning (P1) 

Time recording is based on the ISO-8601 standard. All times are UTC. Since we’ve decided the 

minute is our lowest resolution, no seconds are required. It is assumed that the planning horizon is limited 

to 24 hr, to prevent ambiguity. Note that the “final time” is defined as the end of the Planning period, not 

as the beginning of the last interval. Thus if the planning period was defined as 01:00 to 02:00 with a step 

of 30 min, there would be two steps in the period; one from 01:00 to 01:30, and one from 01:30 to 02:00. 

Details of the automated P1 message are presented in Table 9. 

3.3.1.2 Define Power Constraints (P2) 

Constraints are formatted as ‘The sum of load power consumption must be less than some value in 

watts’. To encode this, each of the load power consumption values is replaced by the load ID# to produce: 

“4+8+2560” which is read as the sum of the power used by loads 4, 8, and 25 must be less than 60W. 

The “+” signs are markers between each of the load IDs, and the “” sign is the demarcation of the load 

IDs from the power limit. If multiple local constraints (constraints limited to a subset of the planning 

window) exist at a single time step, they will be separated by commas. If multiple global constraints exist, 

they will be listed on separate lines. Details of the automated P2 message are presented in Table 10. 

3.3.1.3 Define Load Schedule (P3) 

Note that 0 is a valid priority, and is the highest priority possible, so use of a “0” to indicate the load 

is in the “off” state is not practical. Thus loads in the off state are designated by just a comma. Details of 

the automated P3 are presented in Table 11. 

3.3.1.4 Determine Feasibility (P4) 

Will send content only for violation time steps. Details of the automated P4 message are presented in 

Table 12. 

3.3.1.5 Decision: Re-Plan or Implement (P5) 

The MM will simply send an “Implement” command. Another option is to command “save with a 

name”, but that feature will not be implemented for this simulation. Details of the automated P5 message 

are presented in Table 13. 

TABLE 9.—DETAILS OF P1 COMMUNICATION 

Message Format Example 

P1 Format: 

initial time, final time, delta t (minutes); 

<P1> 

2014-04-01T12:00, 2014-04-01T19:30, 30; 

</P1> 

TABLE 10.—DETAILS OF P2 COMMUNICATION 

Message Format Example 

P2 

T (hh:mm), Pnom, Ppeak, Constraint; 

. . . 

Wh, peak energy available; 

global constraint;

<P2> 

12:00, 6008, 45968,; 

... 

14:00, 6008, 45968, 4+8+25+27+29<60; 

... 

Wh, 8000; 

3+7+26+28<1500; 

</P2> 
NASA/TM—2014-218362 11 

TABLE 11.—DETAILS OF P3 COMMUNICATION 

Message Format Example 

P3 

, T0, T1, ..., Tn; 

Load #, time interval 1 priority, . . ., time interval 

n priority; 

. . .

<P3> 

, 12:00, 12:30, . . ., 19:00; 

1, , , . . ., 14, 18, . . ., ; 

2, , 24, . . ., , 48, . . ., ; 

30, , 18, . . ., 21, ,; 

</P3> 

TABLE 12.—DETAILS OF P4 COMMUNICATION 

Message Format Example 

P4 Time (hh:mm), new constraint; 

. . .

<P4> 

18:30, 3+4+5+6<60; 

</P4> 

TABLE 13.—DETAILS OF P5 COMMUNICATION 

Message Format Example 

P5 Implement;

<P5> 

Implement; 

</P5> 

TABLE 14.—DETAILS OF A1 COMMUNICATION 

Message Format Example 

A1 Format: 

Timestamp, disturbance, impact horizon;

<A1> 

15:03, There was a disturbance,; 

14:35, There was a disturbance, 14:53; 

</A1> 

TABLE 15.—DETAILS OF A2 COMMUNICATION 

Message Format Example 

A2 Format: 

No action; 

<A2> 

No action; 

</A2> 

3.3.2 Automated Asynchronous Communications Cycle 

Automated formats for the two messages comprising a typical Asynchronous Communications 

session are described below. 

3.3.2.1 Inform of Disturbance (A1) 

In the event of a disturbance, the A1 is sent from the APC to the MM. Details of the automated A1 

message are shown in Table 14. 

3.3.2.2 Decision: Re-Plan or Implement (A2) 

Details of the automated A2 message are presented in Table 15. 

 
NASA/TM—2014-218362 12 

4.0 Conclusions 

This paper describes the development of a communication scheme between two key systems in an 

autonomous control system for a manned deep space vehicle. The focus of the effort is the electrical 

power subsystem. A nominal spacecraft power system architecture was described, and prototype versions 

of these two key systems, the Mission Manager (MM) and Automated Power Controller (APC), were 

constructed. 

To develop the communication messages, first a set of rapid-prototyping “paper” simulations were 

run, simulating communication between the MM and the APC under a variety of operational conditions. 

These paper sims enabled development of message content and format necessary to achieve the desired 

goals: negotiation of a load schedule that meets the global vehicle and local power system requirements, 

while enabling communication of off-plan disturbances that arise while executing a negotiated plan. Once 

these messages were optimized, and shown to perform well under nominal and off-nominal conditions, 

they were codified for computer communication, for use in automated testing. A summary of the 

communication formats developed in this paper is included in the Appendix. 

Future work in this area includes the addition of more complex disturbances, such as failures, and 

testing on a hardware system. 

 
NASA/TM—2014-218362 13 

Appendix—Summary of Automated Communication Formats 

A summary of the Automated Communication Formats for Planning and Asynchronous 

communication is included in Tables 16 and 17. 

 
NASA/TM—2014-218362 14 

References 

1. J. Frank, L. Spirkovska, R. McCann, L. Wang, K. Pohlkamp, L. Morin, “Autonomous Mission 

Operations,” 2013 IEEE Aerospace Conference, Big Sky, MT, March 2-9, 2013. 

2. S. Colombano, L. Sprikovska, V. Baskaran, G. Aaseng, R. McCann, J. Ossenfort, I. Smith, D. 

Iverson, and M. Schwabacher, “A system for fault management and fault consequences analysis for 

NASA’s Deep Space Habitat,” AIAA SPACE 2013 Conference and Exposition, September 2013. 

3. J. Frank. When Plans are Executed by Mice and Men. Proceedings of the IEEE Aerospace 

Conference, 2010. 

4. E.E. Smith and D.J. Korsmeyer, “Intelligent Systems Technologies for Human Space Exploration 

Mission Operations,” 2011 IEEE Fourth International Conference on Space Mission Challenges for 

Information Technology, pp.169-176, 2011. 

5. J. Fincannon, A. Delleur, R. Green, J. Hojnicki, “Load-Following Power Timeline Analyses for the 

International Space Station,” Energy Conversion Engineering Conference, 1996. IECEC 96., 

Proceedings of the 31st, August 1996. doi: 10.1109/IECEC.1996.552868. 

6. May, R.D., Dever, T.P., Soeder, J.F., George, P.J., Morris, P.H., Colombano, S.P., Frank, J.D., 

Schwabacher, M.A., Wang, L., Lawler, D., “An Architecture to Enable Autonomous Control of 

Spacecraft,” IECEC, Cleveland, OH, July 28-30, 2014. 

7. Soeder, J.F., Beach, R., McNelis, N., McNelis, A., Dever, T., May, R.D., “Overview of Intelligent 

Power Systems Development for Human Deep Space Exploration,” IECEC, Cleveland, OH, 

July 28-30, 2014.