Thursday, December 28, 2017

Levelized Cost of Energy (LCOE)

Despite the prevalence of its use in the world of energy analysis, and its apparent simplicity, the formulation of common forms of the levelized cost of energy (LCOE) is rarely addressed and the meaning of its parameters is often misstated.

The levelized cost of energy, also known as the levelized cost of electricity, or the levelized energy cost (LEC), is an economic assessment of the average total cost to build and operate a power-generating asset over its lifetime divided by the total power output of the asset over that lifetime. LCOE is often taken as a proxy for the average price that the generating asset must receive in a market to break even over its lifetime.  LCOE is appealing because it is a first-order economic assessment of the cost competitiveness of an electricity-generating system that incorporates all costs over its lifetime: initial investment, operations and maintenance, cost of fuel, and cost of capital.

In the following, we derive the most common form of the LCOE.  The LCOE is the cost that, if assigned to every unit of energy produced (or saved) by a system over the analysis period, will equal the TLCC (total life-cycle cost) when discounted back to the base year [1].  This definition of LCOE is represented by,


r           = discount rate (per year)
i           = year
n          = number of years over which the LCOE applies
Ei         = quantity of energy produced in year i
TLCC  = total life-cycle cost.

Discrete compounding has been assumed in Equation (1).  Since LCOE is by definition constant (not dependent on the year i), we can factor it out of the summation and rewrite Equation (1) as,


Equation (2) is the most common form of LCOE in use today.  Note, the denominator of Equation (2) appears to be discounting the energy (and some references refer to it as "discounted energy"), however, only costs can be discounted; the apparent discounting is actually a result of the algebra carried through from Equation (1) in which revenues (the product of Ei and LCOE) were discounted.

The total life-cycle cost (TLCC) can include several contributions depending on the application.  Commonly it is formulated as,

Ii          = investment expenditure in year i (this assumes that either the investment cost is paid over time or it is allocated over time using a depreciation schedule)
Mi       = operations and maintenance expenditures in year i
Fi         = fuel expenditures in year i (for renewable energy generation, e.g., wind or solar, this may be zero).

Typically, the LCOE is calculated over the lifetime of an asset, which is usually 20 to 40 years.  However, care should be taken when comparing different LCOE studies and the sources of the information as the LCOE for a given energy source is highly dependent on the assumptions, financing terms and technological deployment analyzed.

[1] Short, W. Packey, D.  J. and Holt, T. (1995). A Manual for the Economic Evaluation of Energy Efficiency and Renewable Energy Technologies, NREL/TP-462-5173, March. Accessed April 28, 2016.

Friday, December 15, 2017

Sustainment Vicious Circle

A vicious circle or cycle is when a bad situation feeds on itself to get worse.  Many “systems” (social, economic, ecological, technological) are comprised of chains of events that form feedback loops that can under some circumstances reinforce the previous cycle (positive feedback). 

It is not uncommon for sustainment-dominated systems (see my January 2017 blog post) to get caught in a “sustainment vicious circle” (or “vicious cycle” [1]).  In this case, more money is going into sustainment (maintaining the systems) at the determent of new investment, which causes the systems to age, which in turn causes more money to be required for sustainment, which leaves less money for new investment, and the cycle continues.  The sustainment vicious circle is a reality for militaries of many of the world’s countries, civil infrastructure, and can also appear for systems owned by individuals.  For example, individuals might face this dilemma with their automobile – fixing your existing car is expensive, but it is less expensive than buying a new car; after several such repairs one is left to wonder if purchasing a new car would have been less expensive, but there is no turning back, too much has been invested in repairing the old car (the funds that could have been used to purchase a new car have been spent).

Setting aside your used car, in this blog we are primarily talking about large, complex, expensive systems, like a fleet of aircraft, a fleet of buses, rail infrastructure, the water/sewer system in cities, etc.  These things are massively expensive to replace or upgrade (and massively expensive to sustain).  Let’s be clear, not every large, complex, expensive system suffers the sustainment vicious circle – many are well managed and correctly funded.  However, the evidence of sustainment vicious circles are all around you – look at the neglected portion of a city’s aging infrastructure.  The cause of the sustainment vicious circle is often the inability or unwillingness of system’s owners (which may be the public) to budget appropriately for sustainment (operation and maintenance), which is exacerbated by unanticipated life extensions of the system requiring it to last longer than it was designed (or funded) to last.  The money to build new things is always easier to get than the money to sustain old things AND old things always end up having to be supported longer than anyone anticipated.

How do you get out of a sustainment vicious circle?  Either the system reaches its breaking point (literally, possibly catastrophically) and simply must be replaced, or the system has to be transitioned to a more “vital cycle” that would reduce the sustainment costs of legacy systems, and provide for modernization. Pursuing the “vital cycle” is not cheap (customers have to be willing to pay) and it usually comes with one key caveat: any action taken cannot adversely affect the customer’s needs in the short term.

Corollary to the Vicious Circle – The Upgrade Trap [3]

Related to the vicious circle is the “upgrade trap”.  A common version of the “upgrade trap” is forced upon consumer electronics users.  How often have you been forced to buy a new device because none of your software would run on your old hardware?   The upgrade trap is indiscriminant, even users that derive no actually benefit from higher-performance hardware or greater functionality software, are forced to “keep up” whether they want to or not.  Even systems that are seemingly disconnected from commercial interests such as military systems are impacted, e.g., if these systems contain COTS (Commercial Off-The-Shelf) application software, the continued support of the application may require hardware upgrades that are not otherwise needed or wanted.  Is the upgrade trap by design – certainly, it is a form for planned obsolescence (see my February 2017 blog post).

The one thing that is worse than being caught in the upgrade trap, is not being caught in the upgrade trap, i.e., being caught in the “sustainment vicious circle”.

[1]  Achieving an Innovative Support Structure for 21st Century, PSB 96 (10-13-97)
[2] Sustainment, Proceedings of the Sustainment Team of the Industry Affordability Task Force, Report Number 98-SS1A, National Center for Advanced Technologies, January 1999
[3] P. Sandborn and J. Myers, "Designing Engineering Systems for Sustainment," Handbook of Performability Engineering, ed. K.B. Misra, Springer, pp. 81-103, London, 2008.

Wednesday, November 22, 2017

Cost Avoidance Based Return on Investment (ROI)

The determination of the ROI allows managers to include quantitative, readily interpretable results in their decision-making.  While the formulation of an ROI associated with investing money in a financial instrument is straightforward, the calculation of an ROI associated with the generation of an increase in the customer base, cost savings, or a future cost avoidance is not as simple to determine. 

Financial ROI Calculations - First the financial world’s definition of ROI.  ROI is a common performance measure used to evaluate the efficiency of an investment or to compare the efficiency of a number of different investments. To calculate ROI, the benefit or gain associated with an investment is divided by the cost of the investment and the result is expressed as a percentage or a ratio:


An ROI of 0 represents a break-even situation--that is, the value you get back exactly equals the value you invested.  If the ROI is > 0, then there is a gain; if the ROI is < 0, there is a loss.  Constructing a business case for an activity does not necessarily require that the ROI be greater than zero; in many cases, value is not fully quantifiable in monetary terms, or the activity is necessary in order to meet a system requirement that could not otherwise be attained, such as satisfying an availability requirement.   The calculation of ROI can be modified to suit the situation depending on what you include as returns and investments.  This means that ROIs are easy to calculate but can be deceivingly difficult to get right.  Financial investment ROIs are straightforward, but when evaluating the ROI of a cost savings, market share increase, or cost avoidance, the difference between costs that are investments and those that are returns is blurred.

Cost Avoidance ROI - Cost avoidance is a reduction in costs that have to be paid in the future.  Cost avoidance is commonly used as a metric by organizations that have to support and maintain systems to quantify the value of the services that they provide and the actions that they take.  See my May 31, 2017 Blog post for more about cost avoidance.

Cost avoidance ROI is a bit more difficult to calculate than the financial ROIs.  As an illustration, consider the determination of an ROI for performing condition-based maintenance (CBM) or Prognostics and Health Management (PHM) on a system. CBM uses real-time data from the system to observe the system’s state (condition monitoring) and thus determine the system’s health.  The presence of CBM allows action to be taken only when maintenance is necessary.  The alternatives are to perform maintenance on a fixed schedule (whether it is actually needed or not) or to adopt an unscheduled maintenance policy in which maintenance is only performed when the system fails (i.e., corrective maintenance).  CBM, however, is costly to implement and maintain. Is it worth it? 

To formulate the ROI for adding CBM to a system, we first have to decide what we are measuring the ROI relative to (ROIs must be measured relative to something that is clearly defined).  For our CBM example, we could use the ROI relative to unscheduled or corrective maintenance.  The ROI from Equation (1) becomes, [1]:

Cu      = the life-cycle cost of the system when managed using unscheduled maintenance
CCBM  = the life-cycle cost of the system when managed using a CBM approach
ICBM   = the investment in CBM when managing the system using a CBM approach

The nice thing about equation (2) is that the numerator is the difference of life-cycle costs, i.e., one only has to be able to determine the difference between the two cases (the actual values of Cu and CCBM, which are harder to determine, are not needed) – see my November 2016 blog post on absolute vs. relative costs.  Equation (2) can be derived from Equation (1), note that CCBM is a life-cycle cost that therefore includes ICBM within it.

A second challenge is determining the investment cost (the denominator of equation (2)).  For cost avoidance cases it is not always clear what costs are investments and what costs are the result of an investment.  For example, my CBM approach could result in more maintenance actions (the need for more spare parts) than an unscheduled maintenance approach (since it will cause maintenance to be performed prior to failure); is the cost of the extra spare parts accounted for as part of the investment (IPHM)?  The extra spare part cost in this case would not be included in the investment cost because it is the result of the CBM management approach (i.e., the result of the investment) and is reflected in the life-cycle cost CCBM.

[1] Feldman, K., Jazouli, T. and Sandborn, P. (2009). A methodology for determining the return on investment associated with prognostics and health management, IEEE Transactions on Reliability, 58(2), pp. 305-316.

Monday, July 17, 2017


Should-cost is the result of cost modeling done by a customer to determine what it should cost them to purchase a product, service or system support [1].  Should-costing is based on the customer’s accounting and their understanding of the product or service. When a customer knows a product or service’s should-cost, then they know what they should pay for it.

Why is should-cost a thing?  For many common products, market competition protects the customer from significant overpayments (assuming the customer shops around or allows the market compete for their business).  However, for unique products and services (e.g., military programs, contracted services, etc.), where there is no market competition that sets prices at fair levels, knowing the should-cost is critical when a customer wishes to guard against overpayment.

A common alternative to should-costing is strategic sourcing, which is the process of comparing price quotes from different sources.  Alternatively, should-costing would start from an analysis of labor, materials, overhead, profit margin, etc., to estimate what the price should be.  Strategic sourcing is used for commodity items (e.g., if you are going to buy a washing machine, you shop around), while should-costing is used for highly engineered systems and services where there are few suppliers (e.g., a new aircraft carrier).  A commonly used example is the purchase of a car.  A strategic car buyer goes to multiple dealers to see who will give them the best price.  A should-cost buyer researchers the dealer’s invoice price and how dealers determine their markups and then tells the dealer what price they will pay for the car.

The car buying example aside, in the real world should-cost should be thought of as leverage, not a prediction [2].  Any should-cost analysis you perform will be wrong – there are thing you simply don’t know.  Most people have the expectation that the predictive power of should-cost alone will have the strength to cause the negotiated price to equal the price determined from the should-cost estimate - this is a great goal, but it is not typically realistic.  The point of should-cost is that it gives you leverage to push a quoted price toward your should-cost estimate.

[1] Carter, A. B. and Mueller, J. (2011).  Should cost management: Why? How?, Defense AT&L: Better Buying Power, Sept-Oct, pp. 14-18.

[2] Hiller, E. A. (2012), “Your Should-Cost Number is Wrong, But it Doesn’t Matter,” Industry Week, October 21,  Accessed July 17, 2017.

Wednesday, May 31, 2017

Cost Avoidance vs. Cost Savings

In the case of manufacturing processes, it is reasonable to characterize the value of process, equipment and yield changes as cost savings.  However, the value of life-cycle management activities (i.e., sustainment) is usually quantified as a cost avoidance.  “Cost avoidance is a cost reduction that results from a spend that is lower than the spend that would have otherwise been required if the cost avoidance exercise had not been undertaken” [1].  A simpler definition of cost avoidance is a reduction in costs that have to be paid in the future to sustain a system [2].  

Cost avoidance is commonly used as a metric by organizations that have to support and maintain systems to quantify the value of the services that they provide and the actions that they take.  These organizations do not like to use the term “cost savings” since a savings implies that there is unspent money, whereas in reality there is no unspent money, only less money that needs to be spent.  Another way to put it is, if you told a customer that you saved 100 dollars, the customer could ask you for the 100 dollars back; if you told a customer you avoided spending 100 dollars there is no 100 dollars to give back.

Unfortunately, making business cases based on a future cost avoidance argument is often more difficult than business cases that are based on cost savings, therefore, there is a greater need to be able to provide detailed quantification of sustainment costs.  Requesting resources to create a cost avoidance is not as persuasive as making a cost savings or a return on investment argument. 

[1] Ashenbaum, B. (2006). Defining Cost Reduction and Cost Avoidance, CAPS Research.

[2] Sandborn, P. (2017). Cost Analysis of Electronic Systems, 2nd edition, World Scientific.

Monday, April 3, 2017

Resilient Systems and Resilient Design

We hear the word "resilience" a lot these days.  It's a word that's ripe for misuse and vagueness.  
There is a general agreement that resilience is the intrinsic ability of a system to resist disturbances.  Another equivalent definition of resilience is the ability to provide required capability in the face of adversity (sometimes referred to as disaster recovery).  Resilient design is about managing the ubiquitous uncertainties that constrain current design practices as well as finding ways to overcome an imperfect understanding of system requirements that lead to fragile and ineffectual system designs.

The definitions above are fine, but the real question is what is the “scope” of the system – and this is where views vary.  In this blog we focus on electronic products and systems, however, the concepts of resilience and resilient design are more prevalent in the building construction, architecture, and communities design space.

When you talk about resilient systems, several disciplines think they have a handle on the problem.  The control systems folks think that this is their domain, the optimization folks, the PHM (system health management) folks, the reliability engineering folks, sustainability folks, the system engineering folks, machine learning, artificial intelligence, … In my experience, none of these disciplines (with the possible exception of some system engineers) really grasps the total scope of resilience.  Every discipline wants to gather resilience under their umbrella and grant themselves ownership of the problem space based on their narrowed definition of what a system is.

In my opinion, designing resilient hardware and software (which is the focus of most resilient system design activities) is necessary but not sufficient for creating resilient systems.  For a system to be resilient requires:
  • reliable (or self-managing) hardware and software
  • a resilient logistics plan (including supply chain and workforce management)
  • a resilient contract structure
  • resilient legislation or governance (rules, laws, policy)
  • a resilient business model
One might also include within all of the above aspects, a resilience to changes in the end-of-support for the system.  For many systems, the end-of-support is a moving target that is extended ("life extensions") during the use of the system.

This represents a somewhat broader scope than what is generally articulated in the engineering literature, however, in practice, neglecting any of these elements potentially creates a legacy system with substantial (and potentially untenable) life-cycle support costs.

Although the discussion in this blog has an electronic product/system focus (our "scope").  Resilient design can certainly be applied to other things, e.g., buildings, communities, furniture, information technology, websites, health care, etc.  In this broader world one could consider adding the following to the bullets above:
  • culturally resilient (does the system transcend cultures and culture changes)
  • environmental resilience (sustainability)
  • resilience to climate change

Thursday, February 16, 2017

Obsolescence Definition

Obsolescence isn’t an uncommon word – a Google search finds more than 5.7 million entries.  However, in the engineering design and product support context it has several different meanings.  First, the dictionary definition of obsolescence is the condition of no longer being used or useful. This definition is not inconsistent with the definitions that follow, but it is also not specific enough to provide much value in a product support context.

Planned Obsolescence – we hear this a lot.  Planned obsolescence refers to products (usually consumer products) that are designed to be rendered obsolete by the introduction of another product that has more functionality, higher performance, smaller size, and/or costs less.  Planned obsolescence is a strategy sometimes followed by companies that design and manufacture consumer electronics.  Planned obsolescence is often confused with “made-to-break” products [1].  Made-to-break products are products that are intentionally designed or manufactured to fail at some point in the future (nominally after the warranty has ended) forcing the customer to purchase a new product.

Sudden or Inventory Obsolescence - Sudden or inventory obsolescence occurs when the product design or system part specifications changes such that existing inventories of components (e.g., spare parts) are no longer required.  This type of obsolescence has been studied in the operations research literature.
DMSMS or Procurement Obsolescence – DMSMS (Diminishing Manufacturing Sources and Material Shortages) obsolescence is the loss or impending loss of original manufacturers of items or suppliers of items or raw materials [2].  This type of obsolescence is caused by the unavailability of technologies or parts that are needed to manufacture or sustain a product.  DMSMS means that due to the length of the system’s manufacturing and support life and possibly unforeseen life extensions to the support of the system, the necessary parts and other resources become unavailable (or at least unavailable from their original manufacturer) before the system’s demand for them is exhausted.  DMSMS obsolescence is the opposite of sudden or inventory obsolescence.

Planned obsolescence is a strategy followed by product manufacturers, DMSMS obsolescence is a situation forced upon system sustainers (these two types of obsolescence are not the same).  DMSMS obsolescence may be the result of the planned obsolescence of products that drive the market for specific types of parts, e.g., if your long field life system depends on the same parts that cell phones depend on, then planned obsolescence strategies for cell phones drive the DMSMS obsolescence of the parts you depend on.  The “poster child” for DMSMS type obsolescence is electronic parts.  For some electronic parts the planned obsolescence of particular products is the primary driver behind the part’s obsolescence, but the discontinuance of parts is also simply the result of falling demand that makes it more profitable to dedicate manufacturing resources to other products, or changes in ownership of product lines or companies.

All of the types of obsolescence defined above are relevant for real product and system segments.  While it is easiest to think of these as impacting hardware, obsolescence also has a significant impact on software [3], materials, and even the human workforce [4]. 

[1] Slade, G. (2006). Made to break: Technology and obsolescence in America, Harvard University Press.

[2] Sandborn, P. (2008). Trapped on technology's trailing edgeIEEE Spectrum, 45(1), pp. 42-45, April.

[3] Sandborn, P. (2007).  Software obsolescence - Complicating the part and technology obsolescence management problem, IEEE Transactions on Components and Packaging Technologies, 30(4), pp. 886-888, December.

[4] Sandborn, P. and Prabhakar, V.J. (2015).  Forecasting and impact of the loss of the critical skills necessary for supporting legacy systems, IEEE Transactions on Engineering Management, 62(3), pp. 361-371, August.