Due to the complexity of this topic, I have divided this blog into multiple parts:
– Part 1 introduces resource margins and reserves during development and operations.
– Part 2 goes into more detail concerning the terms associated with resource margins and reserves for mass and consumables from a demand perspective.
– Part 3 goes into more detail concerning the terms associated with resource margins and reserves for resource production from a supply perspective.
– Part 4 focuses on “how” to manage resource margins and reserves over the development life of your system.
A problem that we commonly see on projects is a failure to appreciate the concept of managing resource margins and reserves. In fact, an understanding of this issue is one of the characteristics of a good Systems Engineer per Gentry Lee, of NASA’s Jet Propulsion Laboratory (JPL). In a talk presented by Mr. Lee entitled “So You Want to be a Systems Engineer? Personal Behaviors of a Systems Engineer” he outlined 10 behaviors systems engineers should have, one of which is: “A good systems engineer appreciates and understands the need to manage resource margins and reserves.”
For the purpose of this series of blogs, development/technical “margin” is defined as the difference between the estimated resource value defined at the beginning of project development activities and the actual amount of the resource value at the end of development when the system is delivered. Margins allow for both expected and unexpected change as the design matures over the system development lifecycle. Development margins for resources like mass and power are defined at the system level and allocated to the parts of the system architecture. Operational “margin” is defined as the difference between what is required during operations and what is actually provided. Operational Margin provides additional capability to address unexpected changes that may occur during operations.
“Management Reserve” is defined to be the portion of the available resource held back or kept “in reserve” by management or resource owner during development and not made available through allocation. Reserves allow management to deal with the unexpected such as out of-scope demands, unplanned changes, and other uncertainties.
Note: the focus of this paper is on technical margins and reserves for resources. From a project management viewpoint, it is also important to address margins and reserves for schedule and cost as well.
“Resources”, are a quantity of a “thing” that is critical to successful planning, development, and operations of your system. For software this could be CPU speed, cache memory, bandwidth, amount of data to be processed, storage, number of messages, number of commands over time, number of users, bandwidth, response time, reliability, availability, number of cycles, lifetime, etc. For a system being developed to go into space, resources of interest could be the mass, delta-V (amount of energy to move a mass from one point to another), and electrical power. For a human base on the surface of Mars, resources such as power, fuel (for return), water, food, air, oxygen, hydrogen, and spare parts would be critical resources that need to be managed. From a Program or project management viewpoint, budget, schedule, and risk could be considered resources.
When managing resources for a space mission, a resource like mass, or resources to be consumed or used (power, fuel, water, air, food), a maximum resource requirement will be defined. For consumable resources provided via pre-launch storage or produced during a mission, for a human mission to Mars (power, fuel, water, food, air, etc.), a minimum consumable resource supply and/or production requirement will be defined.
In our requirements classes, we talk about the importance of defining resource needs in the form of requirements for the system as a whole and then the apportionment or allocation of these resources to the systems that make up the next level of the system architecture. In this context, resources requirements are constraints to the development team that they must address in the design of their system of interest.
A key challenge is how to manage these resources over the development and operations life of the system. At the beginning of a project, it is common to do a preliminary analysis and compute an estimate of the various resource needs and then communicate these estimates as requirements. A key issue in managing resources during both development and operations is a failure to understand that these initial computations are only approximations based on assumptions that may or may not be correct and may change as the system design matures. It is also important to realize that many of the resource values are dependent system variables – a change in one affects change in another.
Experienced systems engineers have learned over time that often the projected resource utilization, like mass and consumption rates, are often underestimated and tend to grow over the system development lifecycle. On the other hand, the ability of a system to produce resources (power, fuel, water, food, air, etc.) are often overestimated and the production efficiency of the systems tend to be lower than expected as the design matures. In either case, our knowledge concerning resource utilization and production is directly proportional to the maturity of the technologies being used. The lower the technology readiness level (TRL), the larger the uncertainty of successfully integrating the desired technological implementation, or system capability. As the design matures, parts are procured and integrated together; the knowledge of the actual mass, consumption, and production numbers will mature. (To learn more about TRLs, see my blog: “Using Technology Readiness Levels to Manage Risk”.)
For human space exploration missions, the appreciation of the need to define and manage resources margins and reserves is a very real issue. For example, resources like mass, delta-v, and power consumption are dependent variables that drive all design activities. For a human mission to Mars, a big concern is defining the mass that needs to be delivered to the surface for the mission duration, or keep them alive if they are required to abort to Mars until rescued. This mission-required mass in addition to the delta-v rocket capabilities, drives the number of launches from the surface of Earth required to get the necessary mass to low Earth orbit. Additionally, the size and number of the transfer vehicle(s), amount of fuel needed to get the mass to the orbit of Mars, and then the size and number of landing vehicles and propulsion needs to put that amount of mass on the surface of Mars is also affected. Failing to recognize that these resource needs (and ability to fulfill these needs) will change over the development lifecycle can lead to a system that cannot carry out the intended mission given cost and schedule constraints for the Program.
Consumable resources, the resources that will be consumed during the duration of the mission, can be supplied by bringing them with you (the store), or you can produce them once you get there, or both. The store represents mass and volume which needs to be accommodated in the mission design. The store can also be resupplied via re-supply missions, which are very costly, with a limited delivery schedule dependent on distance and orbital dynamics (~2-years). A key strategy to reduce the store and thus the mass that needs to be delivered to the surface of Mars (the store) is in-situ resource utilization (ISRU)– live off the land. (For more detail on the need for ISRU is contained in a paper published by NASA engineers at Langley Research Center in Hampton, Virginia. You can access this paper at: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20160005963.pdf)
Using ISRU, the required storage (mass and volume) delivered to the surface is reduced by relying on the ability of surface systems utilizing in situ resources (gases in the atmosphere, water in the soil, minerals in the soil, etc.) to produce the needed resources in excess of the store’s capacity. For a base on Mars, currently the TRL is very low for these types of in situ resource production systems; therefore, our uncertainties are high concerning our knowledge of our resource consumption and production needs. Failing to recognize these resource consumption estimates tend to grow, and at the same time the production efficiency estimates tend to be less, can lead to an imbalance in the system, leading to a system that cannot facilitate the intended mission.
If the production efficiency turns out to be lower than needed, the solution may result in a “bigger” system to meet the resource production needs. Bigger, means more mass, volume, and most likely, more power. If this is not practical, the shortfall will have to be made up by increasing the size of the “store”, which again means more mass and volume to be delivered to the surface. If the maximum-allowable mission mass is a fixed variable, then the mass required for the “bigger” system or larger store will have to be taken from the margins of other systems or from the management reserve, assuming adequate margins and reserves have been defined and are available. The same is true for power and other consumable resources. Alternately, the scope/objectives of the mission may have to be reduced to account for the reduced production capability.
Management and tracking of mass, consumption, size of the store, and production efficiency during development is a significant responsibility of the program manager and systems engineer. Failing to do so, from the beginning of the project, is a very significant issue of a program of any size, but especially for a program sending humans to Mars, returning them home safely, or setting up a permanent presence.
Not appreciating and understanding the need to define and manage adequate margins and reserves during development, can result in a program having massive cost overruns, schedule slips, and in the end, cancellation. If not cancellation, the the risk of loss of mission and loss of life is going to be much higher if there isn’t a sufficient operational margin during the mission.
Operational Margins
In the previous section operational margins were defined, however the focus was on margins and reserves during the development of a system. In this section, the concept of margins is discussed after the system is put into operations.
During operations resource consumption needs and production efficiencies must take into account not only nominal operations, but also alternate, off-nominal operations. During production, resource consumption needs and production capability were based on assumptions, and these assumptions may not be valid due to a lack of actual operational experience for the specific project or the reliance on systems using technologies with lower levels of maturity (low TRLs), e.g., this is the first time the system is actually used for this specific purpose in this actual operational environment. There are also the unknown unknowns that are sure to occur.
For example, you are rolling out a new version of software. This software turns out to be very popular. The number of people wanting to acquire the software overwhelms the servers and network capabilities and there are either very long wait times, slow download speeds, or the servers crash. Or how about a new online government system that crashes because of the unexpected large number of concurrent users that are trying to set up new accounts and log in or the other systems this system interfaces with were not designed for that peak volume. The system was designed based on an estimate of the average number of users on any given day. The initial peak of the number of users (demand) at the beginning or surges in demand were not considered, or at best, underestimated, thus the ability to supply the services during peak periods was exceeded causing the system to fail.
For a space mission, a maneuver may use more propellant than planned. Think about the first moon landing – they landed with the propellant tanks almost empty. A few more seconds and they would have crashed! Think about a manned mission on Mars, and the leak rate of air in the habitation module is more than planned for (greater demand), where does the extra air come from if the atmosphere generation system was designed to supply a quantity of air only for nominal conditions based on incorrect assumptions? Or consider the Mars Accent Vehicle propellant needs. What if the actual fuel production rate, storage leak rates, or delta V (energy) required to reach the Mars-to-Earth Transfer Vehicle are different that assumed?
On the flip side, as stated earlier, resource production rates or efficiencies tend to be overestimated. What if the actual production rate (power, fuel, water, food, air, etc.) is lower than estimated? Or one of the logistics modules containing vital resources and spare parts that were intended to add to the “store” crashes on landing? Where will the additional supply of these lost resources come from if the production rates from in-situ sources are less than assumed?
In our previous blog on developing agile systems, we said one of the attributes of an agile system was the use of an Operational Margin in order to reduce risk of unexpected things happening during operations whether the unexpected is an increase in demand or a reduction in supply.
Operational Capability goes beyond what the Nominal Resource Demand and Nominal Resource Supply are for nominal operations. Operational Capability provides additional resources during surge or peak consumption periods as well as enabling the system to succeed even when the unexpected happens. Operational Capability also provides additional resources when operational conditions or the environment are different from those assumed when the system resource requirements were generated and the system was designed to meet. The ability to do an extra maneuver, to take longer to land, to make up for an unexpected leak rate, to handle a surge in demand, to survive in environmental conditions different than those expected, or make up for a production rate that is lower than expected; are only possible if margins for these contingencies were included in the resource demand and supply requirements that drove the design.
From the supply side of the resource balance equation, you can define Operational Margin as the difference between the Nominal Resource Supply and Operational Capability.
Operational Margin = Operational Capability – Nominal Resource Supply
Operational Capability = Nominal Resource Supply + Operational Margin
From the demand side of the resource balance equation, you can define Operational Capability to include both the Nominal Resource Demand plus an additional value for possible Increased Resource Demand.
Operational Capability = Nominal Resource Demand + Increased Resource Demand
Combining equations, we have the resource balance equation:
Nominal Resource Demand + Increased Resource Demand <= Nominal Resource Supply + Operational Margin.
We can balance this equation because we have included an Operational Margin on the supply side of the equation to address the possible Increased Resource Demand on the demand side of the equation. The mission was successful and all tasks were able to be completed, in spite of unexpected issues, because our Operational Capability acknowledged a possible Increased Resource Demand and included an Operational Margin on the supply side of the resource balance equation that was able to accommodate that increase.
Operational Margin can also be used as a tool or measure to track the current consumable resource status of the system during development. For each consumable resource, the current ability of the system to produce a quantity of the resource (supply) is tracked vs the total nominal quantity needed (demand) during the mission, plus the Operational Margin. For example, the propellant quantity requirement will include a propellant Operational Margin in addition to the nominal propellant necessary to complete the mission. The water extractor output requirement will include an Operational Margin in addition to the nominal volume of water needed to be extracted to allow for both changes in demand as well as changes in the ability of the water extractor to extract water.
Because we included in our resource (supply) requirements an Operational Margin beyond the nominal value, we have an Operational Capability that enables us to succeed when the actual operational needs (demand) or environment are different than what we assumed during development. Including an Operational Margin, we are able to mitigate risks due to uncertainty, incomplete knowledge, and the unknown unknowns.
For an organization to launch a human mission to Mars with inadequate Operational Capability, could very well lead to a loss of life and a loss of mission.
In Part 2 we address the demand side of the resource balance equation by going into more detail concerning the terms associated with resource margins and reserves for mass and consumables.
In Part 3 we address the supply side of the resource balance equation by going into more detail concerning the terms associated with resource margins and reserves for resource production.
Comments to this blog are welcome.
If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.
