Fixed and variable overhead capacity per site

07 November 2014

STEM 7.4 includes a long-awaited refinement to the calculations for geographical deployment in the case when a resource specifies a Maximum Utilisation constraint too. We have also introduced a new Minimum Slack Capacity input which demands a fixed overhead of slack capacity in addition to the variable overhead for Maximum Utilisation.

This article is an extract from the new documentation for STEM 7.4 and describes the interaction of these two overheads with the existing calculations for geographical deployment, complete with relevant examples.

1. New models will Deploy With Utilisation

When the Maximum Utilisation feature (MU) was added to STEM, it was considered quite separately from Deployment, so that:

  • the MU constraint considers only total demand (ignoring sites)
  • the deployment calculation allows for the notional utilisation of resources at each site to vary from 0 to 100% (rather than the lower percentage which may be envisaged by the Maximum Utilisation input).

This behaviour was unintuitive at best and so STEM 7.4 now limits the range of notional utilisation at each site to 0–MU if the new input Deploy With Utilisation = Yes (which is the new default behaviour). Utilisation at the ‘hottest’ site will not exceed MU, and will be proportionately lower at other sites (as shown in the two figures below), resulting in lower overall utilisation than without the MU constraint.

Figure 1: Illustration of original interpretation with Deploy With Utilisation = No

Figure 2: Illustration of refined interpretation with Deploy With Utilisation = Yes

Thus, a Maximum Utilisation constraint will now impact the Installed Units result directly. Previously (or with Deploy With Utilisation = No ) it would only make a difference if the specified overall Maximum Utilisation was lower than that which would already result from an existing allowance for deployment.

These new installation results will match those of an unconstrained resource with equivalent input Capacity = c . MU (where c is the Capacity of the original resource), whereas this was not so before (or with Deploy With Utilisation = No).

Legacy behaviour

STEM 7.4 will set the input Deploy With Utilisation = No for all resources when loading an older model in order to maintain the original results. However, you may wish to review those results (and this setting going forward) if any resources in your model do combine the Maximum Utilisation and Deployment features.


Consider a resource with the following input characteristics and for which the overall demand gradually increases from zero to 1000 subscribers over ten years:

  • Capacity = 50 Ports
  • Maximum Utilisation = 80%
  • Sites = 10
  • Distribution = Monte Carlo.

Figure 3 below compares the original (STEM 7.3) results for two scenario variants, Lean and Variable, which switch the Maximum Utilisation input between 100% and 80%.

Figure 3: No difference with Maximum Utilisation when Deploy With Utilisation = No

The chart on the right (where Maximum Utilisation = 80%) looks exactly the same! Indeed, there is no difference at all, because the Deployment calculation already results in sufficient slack capacity for the Utilisation Ratio result never to exceed 78%.

Figure 4 below shows the results for a third scenario variant, Variable NEW, which in contrast sets the new input Deploy With Utilisation = Yes.

Figure 4: Increased overhead with Maximum Utilisation when Deploy With Utilisation = Yes

You can see that a greater overhead of slack capacity is installed; in addition to the more or less fixed geographical overhead (roughly 250 ports), now there is also a variable component (in proportion to the demand) which amounts to another 250 ports by the end of the model (equivalent to the 25% of demand required to ensure that utilisation would not exceed 80% at any one site). The combined effect results in an overall utilisation which never exceeds 66% within the model run.

(You may find it instructive to consider how the installed units would compare for a resource with inputs Capacity = 40 Ports and Maximum Utilisation = 100%; i.e., the same effective capacity of the original resource.)

2. Fixed and variable overhead capacity

The Maximum Utilisation input tells STEM to install an additional variable amount of slack capacity (usually bandwidth) in proportion to the nominal total demand to allow for transient peaks in usage. Other situations call for a fixed overhead of spare capacity (typically ports) which might be reserved as immediately available spare capacity in the event of card failure or to enable rapid provisioning for new customers.

This fixed overhead for a resource can now be specified explicitly with a new Minimum Slack Capacity input (MSC), found in the Capacity and Lifetime dialog:

  • in the simpler case where there is no geographical Deployment to consider, STEM adds this MSC to any non-zero required demand before rounding up to determine how many units must be installed, thereby ensuring that there will always be the slack capacity required for as long as there is any current demand
  • the MSC input is ignored if there is no current demand for a given resource
  • the MSC input is not limited to the unit Capacity of a resource, so it can lead to multiple, wholly slack units being installed if so required.

For a resource with inputs Capacity = 50 and Minimum Slack Capacity = 15, the effect is just that the next unit will be installed when the demand exceeds 35, 85, 135, etc., rather than the usual 50, 100, 150 and so on.

Minimum Slack Capacity and Deployment

STEM will allow for the same fixed overhead at each site if the new input Deploy With Utilisation = Yes. Otherwise it is only applied as a single overhead on the overall demand.

Figure 5 below compares the results for two scenario variants, Lean and Fixed NEW, which switch the Minimum Slack Capacity between 0 and 15 ports, respectively, in a situation where the overall demand gradually increases from zero to 1000 subscribers over ten years (with a Monte Carlo distribution over 10 sites).

Figure 5: Additional fixed overhead with Minimum Slack Capacity when Deploy With Utilisation = Yes

The deployment calculation allows for the notional slack capacity at each site to vary in the range 15–65 ports (average of 80% of a unit) rather than the unconstrained 0–50 ports (average of 50%), resulting in an extra 10 × 30% slack capacity (equivalent to three more units; i.e., the 150 subscriber difference you can see on the chart).

Minimum Slack Capacity and Maximum Utilisation

The variable overhead required by a Maximum Utilisation constraint makes most sense for a continuously variable demand like bandwidth where some operational headroom is often left to allow for temporal fluctuations in demand. In contrast, the fixed overhead of Minimum Slack Capacity is more likely to be used for a discrete capability such as ports where it is common to leave some capacity free for immediately available spares, or to minimise delay when adding new customers. Therefore, it is unlikely in practice that the two effects will be required for the same resource.

However, it is not an error to specify both inputs in parallel and the resulting calculation is additive: STEM installs sufficient capacity to allow for the specified minimum slack in addition to the variable overhead on top of the basic demand. In the single site case, the capacity installed for a demand, d, will be at least d/MU + MSC. STEM does not apply the maximum utilisation overhead to the minimum slack part as this is not required if the minimum slack represents spares which are available to swap with other used parts.

Alternatively, if the minimum slack is capacity reserved for adding new customers, then an inflated capacity would have to be reserved to allow for the usual maximum utilisation to hold if/when those customers are added. Therefore, if CB is the intended customer buffer, then you should consider setting the input Minimum Slack Capacity = CB/MU. The resulting capacity installed at a single site will be at least d/MU + CB/MU = (d + CB)/MU.

For a resource with inputs Capacity = 50, Maximum Utilisation = 80% and Minimum Slack Capacity = 15, the combined effect is that the next unit will be installed when the demand exceeds 28 (= 35 × 0.8), 68, 108, etc., rather than the usual 50, 100, 150. This allows for at least 15 spares, or the potential to add 12 (= 15 × 0.8) customers without having to install an extra unit.

Free subscription when we review your business model

How well do you understand your business? It may be profitable now, but how prepared are you for this to change? We have a track record of analysing individual services or entire businesses in an interactive workshop style that engages and informs. Our visual software enables multi-disciplinary dialogue about the business you thought you knew and the more uncertain future ahead.

Read the article

STEM User Group Meeting 2017 proceedings

Our most recent customer event was held on 27–28 September 2017 at King’s College, Cambridge. The modelling track explored three growth models for a start-up business, from unconstrained to measured to driven. The remainder of the event covered the forthcoming STEM version 8.0, the revised business model for Implied Logic, and two guest presentations.

Read the article

A freshly baked model of a start-up

We examine Michaela’s Best Bread Direct service, from her first unconstrained vision, through a more realistic measured phase and finally to a more ambitious, customer-driven approach. We demonstrate how STEM can be applied to almost any business topic and always delivers a systematic and reliable treatment of time and money.

Read the article

Business-case design and training at your service

Ever wondered what we do at Implied Logic? We have recently posted a comprehensive update to our services portfolio online which is effectively a self-service proposal for everything from online training on-demand through to on-site business-modelling consulting and hosting services for business models on the web.

Read the article

Connecting elements to graphs and publishing online

In what is likely to be the final preview article for the forthcoming STEM version 8.0, we explore visual connections between individual icons and a related graph, as well as intuitive, interactive options for adding an element to an existing graph. We also explore new layout options for pushing a presentation of results in STEM to the web.

Read the article

Our latest help and training materials

Documentation is never regarded as a very exciting activity, but our comprehensive help and training materials are a vital element of the self-serve experience with STEM. In the last quarter we have posted two significant updates to our online help site which enhance both of these aspects.

Read the article

A radical re-think on STEM pricing

We announce a new freemium strategy for accessing the STEM software, including a free and fully-functional demo system for small projects and study as a taster for an innovative minimal-support subscription to the Conventional STEM (C-STEM) desktop solution at just GBP 330 p.a..

Read the article

Vision for the forthcoming STEM 8.0

As part of our vision for a more intuitive way of working that bridges previous mental leaps wherever possible, we preview another two features of the forthcoming STEM version 8.0 – direct-draw connect mode and more flexible user data – that form part of a joined-up approach to fulfilling this dream.

Read the article

© Implied Logic Limited