STEM keeps track of the age of each installed unit of Resources within a model. When a Resource reaches the end of its life it is replaced. The effective physical lifetime of a Resource is either assumed to be precisely the Physical Lifetime input, for all units of that Resource; or to follow a statistical distribution, with mean specified by the Physical Lifetime.
Redundant Unit Decommissioning Proportion
Units of a Resource are considered to be redundant if they are unused and are not required to satisfy any utilisation or deployment constraints.
For each Resource, the Redundant Unit Decommissioning Proportion input specifies a proportion of any redundant units that should be removed (written off) in a given year. This removal is made after Resources have been installed to meet incremental demand according to Resources Required, and to satisfy any utilisation or deployment constraints, and therefore does not affect either.
Units of a Resource can become redundant due to:
- a fall in Service demand
- an increase in the Maximum Utilisation input
- a reduction in the number of sites at which a Resource is deployed
-
migration of demand away from the Resource, through a Resource Requirement Churn Proportion – see 10.3.2 Churn.
Decommissioning Cost
When Resource units are removed, as a result of reaching the end of their physical lifetime or because they are being decommissioned early, a Decommissioning Cost is incurred. In addition, any remaining Written-Down Value for those units is written off as Depreciation in that year. Once a Resource unit has been removed, no further running costs are incurred.
Note: For the benefit of cost allocation, STEM actually writes off the remaining value in the last year that a Resource unit is still installed, except in the case of early decommissioning of redundant units.
Note: The decommissioning age factor applies relative to when the resource comes to the end of its physical life. This differs from the other age factors, which apply relative to the start of the resource's acquisition – see 10.3.7 Cost Trends and Age Factors.
If an asset has a used or scrap value, its sale upon decommissioning may actually yield more from the cost of removing the asset from the network. From STEM 7.1 onwards, this can be captured by specifying the Residual Value of a Resource, which represents the price that can be obtained for it when it is decommissioned – see 10.3.9 Depreciation, Amortisation and Net Fixed Assets for more details.
Slack equipment bias
Two choices govern how the model engine manages slack capacity, and specifically, how that slack capacity is distributed across different installation ages.
Use Slack
If a Resource has some slack capacity, and demand for that Resource increases, then the Use Slack input allows you to choose whether that slack capacity should be taken up evenly across all installed ages of the Resource, or whether the oldest or newest slack capacity should be used first.
Example
Suppose we have a network in which four units were installed historically. The oldest unit was installed in Y-3, one in Y-2, one in Y-1 and the last in Y0. The Physical Lifetime of the resources is 7 years, with a Capacity of 25 connections. The units will be decommissioned if they are redundant to reduce operating costs. Now let’s assume they became slack, but they can support a new service, which starts in Y0 and grows by eight connections per year. The key question is which equipment (of which age) is going to support the new connections. This is controlled by the Use Slack input.
Let’s have a look at the end of Y1. All four units could still be in the network as the lifetime of the oldest unit only expires by the end of the Y3. We need to support eight connections.
- If the new connections are being supported by units of all ages evenly (Use Slack = Even): we would see two connections supported by each resource and all four resources still in the network.
-
If the new connections are being supported by the oldest resources first (Use Slack = Oldest): we would see all eight connections supported by the oldest resource (Y-3) and the other three resources removed, as they were without demand and therefore redundant.
-
If the new connections are being supported by the newest resources first (Use Slack = Newest): we would see all eight connections supported by the newest resource (Y0) and the other three resources removed, as they were without demand and redundant.
Now let’s have a look at Y4, where we need to support 32 connections and therefore at least two resources:
-
When Use Slack = Even, the oldest unit (Y-3) would be removed from the network due to expiring physical lifetime. The remaining three resources would support 10.6 connections each.
-
If the new service is being supported by the oldest resource (Use Slack = Oldest), the resource from Y-3 must be replaced by a new one due to expiring physical lifetime and a second resource is required to support a total of 32 connections; therefore, two incremental resources must be installed in Y4.
-
If the new service is being supported by the newest resource (Use Slack = Newest), a second resource is required to support a total of 32 connections; so, we have one incremental resource installed in Y4 and one resource pre-existing from Y0.
Make Slack
If demand for a Resource falls, either because Service demand falls or because capacity is churned to another Resource, the Make Slack input allows you to choose whether capacity should be made slack evenly across all ages, or whether the oldest or newest equipment should be made slack first.
The default is Even for both inputs, preserving the behaviour of previous model engines; but selecting Oldest or Newest may be more realistic, and will help avoid small amounts of residual slack in each age if you are using redundant unit write-off.
Example
Suppose we have a network in which four units were installed historically. The oldest unit was installed in Y-3, one in Y-2, one in Y-1 and the last in Y0. The Physical Lifetime of the resources is 10 years with a Capacity of 25 connections. In order to reduce operating costs, the units will be decommissioned if they become redundant.
Suppose the network is supporting a demand of 90 connections until the end of Y1. If this demand was growing in the past it was probably supported by the oldest units first; so, at the end of Y1, three older units were fully utilised (3*25) and the newest resource supported 15 connections.
Now let’s assume that the demand declines by 15 connections per year (1/6) so that, at the end of Y2, the network needs to support only 75 connections. The key question is which equipment (of which age) was supporting the 15 connections.
- The connections could have been spread over all ages evenly (Make Slack = Even): thus, all the resources would still be used, with 1/6 connections less on each (the Used Capacity is 3*20.8 and 12.5 on the newest).
-
The connections could have been supported by the oldest resource (Make Slack = Oldest): again, all resources would be used, supporting 10, 25, 25 and 15 connections each (unit installed in Y-3, Y-2, Y-1, Y0, respectively).
-
The connections could have been supported by the newest resources (Make Slack = Newest): in this instance we would be able to decommission the newest resource, which was supporting 15 connections, resulting in three resources, each supporting 25 connections.