The Case for the Support Case…

Aspire has recently been called upon to prepare two Support Cases, one for a capital equipment programme and the other for a single equipment of moderate complexity. In neither instance have Aspire been involved in the greater Support Engineering programme, so we are compiling these Support Cases using the outputs, the ‘evidence’ (that the system is, or is not, supportable) that has been generated by others; we are coming somewhat late to the party. 

This is not the most efficient way to generate a Support Case, hence this paper which discusses the WHY, WHAT and the HOW of producing a Support Case; a key element of the Systems and Systems Engineering approach to Support Engineering.

The concept of the Supportability Case, or Support Case as I prefer to term it, has only relatively recently become a ‘more’ official requirement in the UK, as it is now defined in Def Stan 00-600 (it was covered by JSP 886 Part 9).  

The concept has been around for some time however, we were discussing and applying the concept for at least a decade before it appeared in JSP 886 (in 2010), evolving as it seemed to do in the Defence sector, initially from the Safety Case, and then the Reliability and Maintainability Case.

There is now a bewildering array of standards which directly or indirectly address engineering ‘cases’ in one form or another, and there is even a generalised IEC standard (IEC 62741:2015) addressing ‘Dependability’ (reliability, availability, maintainability, supportability, usability, testability, durability etc).  

However most programmes fail to fully capitalise on the Support Case, not realising perhaps either how powerful this concept is, nor how easily it can be implemented, if the concept, and its relationship to other Support Engineering activities (i.e. Planning) is fully understood.

Why do I prefer ‘Support Case’ to ‘Supportability Case’? Basically, it’s because I am pedantic and because semantics are vitally important. The term ‘Supportability’, implies (to me at least) that the case is concerned with the design, with the ‘supportability’ of the Mission System, whereas we must consider the entirety of the Support Solution when we “make our case” This means that we need to consider the Supportability of the Mission System and the nature of the associated Support System, taking cognisance, in both cases, of the operational environment, the Employment Plan.  

WHY ?

Let’s start with a discussion of WHY, why a Support “Case” - because this is the key to all that follows.

The reason is simple, it is not possible to ‘prove’ that a system is supportable, to prove that adequate (never mind optimal) support arrangements are in place. Nor is it possible to prove that we really have taken the Employment Plan into account; and this is equally true for safety and reliability of course.

On our LSA course I make this point by handing one our delegates an ancient disk drive and asking them to estimate its mass, which they do, with varying degrees of confidence. You could of course weigh the device; and you could, if necessary, calculate the mass from the dimensions and material specifications found on a drawing, before the first prototype was manufactured. 

If I then hand the device to second delegate and ask them to estimate the reliability, to predict the failure rate, they are confounded, because on consideration they quickly conclude that it cannot be done. Now we could ‘measure’ reliability by testing the item, but any reliability testing, apart from being very expensive, (and increasingly overlooked even on major, safety critical, programmes) will only ever provide an indication of the reliability of the item or system. Testing gives you a reliability figure and an associated degree of confidence. More confidence requires more testing – often a lot of very, very expensive testing. If you are lucky, the confidence level may be as high as 80%, but even that is based on a particular, narrow definition of the operating conditions, conditions that are often only simulated, or approximated, during testing. But the real problem is that if you are relying on testing the system, you’ve already missed the best opportunity to improve reliability.

A similar argument applies to virtually all Support products and to all the other support related factors (i.e. design factors, other than Reliability and Maintainability, that impact Mission System supportability). Consider an initial provisioning list, how can you tell by looking at it, that is ‘right’ i.e. that the range and the scale are both correct, both optimal? If you read a draft maintenance manual you can probably tell if it is well written, but it is very difficult to spot either nugatory or missing content, you cannot tell if all the tasks are adequately described, that the correct resources have all been identified.

When looking at a Mission System design it is not possible to determine if the optimal standardisation requirements have been incorporated, or if the design has effectively addressed long term support risks, such as obsolescence. We also have to consider, that many of supportability factors that are inherent in the Mission System design cannot be quantified (standardisation, system architecture, obsolescence, etc); so how do we determine if the system meets the requirements or not? 

The answer is that we can’t, that is we cannot ‘prove’ that a Mission System is supportable, or that the Support System is effective, not without using it in anger for an extended period (i.e. years) in a real operational environment and seeing how it performs, but then it is all too late of course. 

This is why we have to adopt an alternative approach, one based on a fundamental quality management concept; i.e. that it is good processes that deliver quality.  

It follows logically therefore that if we can demonstrate that good processes are being applied, then we can be assured that a quality product, in our case an optimal Support Solution, will result.

WHAT?

A Support Case is essentially a collection of evidence, evidence that good process will be applied (i.e. we have robust, costed, resourced plans), is being applied, or has been applied. This evidence ‘assures’ us that we have an effective, possibly optimal, Support Solution – or otherwise.

So how does this relate to Systems and Systems Engineering? Well we need to go back to one of my hobby horses, the simple idea that we have to address, and to clearly differentiate between, both ‘Product’ and ‘Process’ when implementing a Support Engineering programme, viz:

1.      The System = the Product which in this case is the Support Solution (the support aspects of the Mission System, the Support System and the Employment Plan).

2.      Systems Engineering = the Process or Processes by which that Support Solution is developed, which in this case is the implementation of Support Engineering, or ILS if you prefer.

These processes are comprised of all the things we do, or are supposed to do, on an ILS/Support Engineering programme, for example:

a)      Develop strategies

b)      Prepare Plans

c)      Develop requirements

d)      Address standardisation

e)      Conduct FMECA and RCM analysis

f)       Identify, define and mitigate long term support risks

g)      Conduct Task Analysis

h)      Collect and collate Lessons Identified [LI’s]

i)        Conduct Training Needs Analysis [TNA]

j)        Conduct reviews

k)      Prepare Reliability Block Diagrams [RBD’s]

l)        Hold workshops

m)    Implement a Reliability Growth Programme

n)      Conduct trials and testing

o)      Etc, etc, etc

It is these processes, and many others, that not only produce the required result, but which also provide the evidence, the ‘body of evidence’ that you will see referred to in the various ‘case’ standards.

But the existence of a process alone is not sufficient, the process has to be a sound one, it has to be applied comprehensively, it has to be applied competently, it has to be recorded so that an effective audit trail is maintained AND, most important of all – someone has to actually use the results…

There is no point conducting an FMECA (a Process) if the results are not used to determine maintenance requirements (which inform the Maintenance Plan – a Product) or to drive improvements in the Mission System design (a Product). There is no point collecting Lessons Identified (i.e. Feedback) if the results are to lurk unused in some forgotten filing cabinet or in folder in a remote corner of the programme’s server. 

If however it can be demonstrated that the FMECA was performed competently, by experienced analysts, using sound design information, taking cognizance of the operational environment, using robust FMECA tools, that it was subject to peer review, that it was then used to identify corrective and preventative maintenance tasks; then we can have a high degree of confidence in this piece of evidence.

If Lessons Identified are treated formally, as say a Design Observation would be, and used to inform requirements, if it can then be demonstrated that those requirements impacted the Support Solution design (i.e. the design of the Mission System or the Support System) or if they were used to improve the engineering process, then we can have a high degree of confidence in this evidence. 

This, and other quality evidence, taken collectively would give us a high level of confidence in the overall Support Solution, we could be reasonably confident that such a solution was optimal; it would give us the necessary ‘Assurance’.

The more examples that we find along these lines, e.g. that an effective Level of Repair Analysis [LoRA] was being conducted, and that the results are being utilised effectively, then the stronger our ‘Case’ becomes. 

Thus, the results of the Support Engineering process provide the evidence, the assurance, that the Support Solution is a sound one, i.e. that it is optimal (within the given constraints) that it is cost effective, that it is affordable, that the requisite operational capability will be realised and that it will be sustained. 

HOW?

I implied above however that it is easy to implement an effective Support Case, how can this be? 

The answer is that it is easy, if you plan effectively, because any meaningful plan starts by defining the desired output (the Product), it then goes on to describe how that output will be achieved (the Process). 

If you create a programme schedule, using MS Project say, you start by developing a Work Breakdown Structure [WBS] i.e. you define activities, the work, that you need to do. Each task within this WBS is then defined, resourced, its dependencies identified, etc – i.e. you produce a Gantt Chart (or a PERT chart). These are both essentially process flow charts, and those processes should all, ultimately, terminate in your desired output, the product.

In the world of Support Engineering, those outputs typically evolve over time, passing through a series of defined stages. For example, having conducted FMECA and RCM we will have a list of corrective and preventative maintenance tasks. Later we will conduct LoRA and determine the optimal level of repair, we will go on to conduct Task Analysis, and to reiterate the LoRA, we will conduct Spares Optimisation, Training Need Analysis [TNA] etc. Throughout this we can see our Technical Manuals, our Maintenance Plan, our Supply Support and Training solutions evolving as a result of these processes. 

Those processes therefore also determine what evidence you are going to produce and when, i.e. they define the content of the Support Case – one of the earliest pieces of evidence being the plan itself. 

In order to render a complex Programme manageable, it is common practice to prepare programme plans for each Support Engineering discipline, hence we have programme plans for Technical Data, Reliability and Maintainability, Support and Test Equipment etc. Likewise, we may breakdown a large and complex Support Case into these same, or similar, categories. 

The UK MoD has defined 18 such categories, which it terms “Support Elements” and we can assess the available evidence associated with each Support Element and allocate a “Support Maturity Level” [SML] to each.  There do not appear to be any hard and fast rules for defining SML’s, but the UK MoD has prepared guidance defining what it would expect to have been achieved for each of nine Support Maturity Levels for each of those Support Elements (a useful piece of work that deserves greater visibility).

We also have to consider that, for a large programme, we may wish to create a separate Support Case for each major sub system, for example on a maritime programme, we may wish to render the process more manageable by addressing the propulsion system, the weapon systems and the communication systems independently. 

The following diagram illustrates the concept.

There can be a significant volume of evidence, ranging from raw data, model input and output data, FMECA and RCM results, through to a wide range of reports, meeting minutes and plans, etc. This has to be managed, structured methods are required; consideration should be given to establishing a register for this “body of evidence” and to establishing a mechanism for assessing and recording the SMLs etc. All of this is achievable with a relatively simple database however.

Ultimately, this will enable the analyst to claim, with some confidence, that the target system, the product, is, or isn’t supportable, that it will or it won’t be able to deliver the requisite operational capability.

Imagine now attending a regular programme review for which you need to prepare the Support Engineering contribution. All the information you require should be at your fingertips, you have the evolving solution - the Product - and the evidence that this is a good solution – or otherwise; that is you will have the results of the FMECA, the LoRA, the RCM, the Task Analysis, etc which comprise your body of evidence. Preparing for such a review should require you to print a few reports and to then prepare an overarching brief – i.e. your Support Case Report or Reports. 

Hence if you prepare a robust programme plan, if you implement that plan, and if you keep good quality, ‘accessible’ records, in order to maintain an audit trail, then you have all the key elements of the Support Case The only additional effort imposed by the Support Case, is the application of the SMLs, everything else should occur as a matter of course on a well-run Support Engineering programme.

FOUNDATIONS: STRATEGIES – PLANS and REQUIREMENTS

I stated above that one of the earliest pieces of evidence would be the Support Engineering Plan, including the programme schedule which forms its core. But it is not the earliest piece of evidence; prior to any plan being written you need a reason for the plan, or more accurately, you need a reason, a justification, for the desired output, a reason for developing the Product. This is the first piece of evidence, the start of the Support Case.

For anything but the most simple programme, it would then be wise to develop a programme strategy - that is we need to consider the context in which the Support Engineering programme is to be implemented and then we can define the best way to proceed given the schedule, financial, resource and skill constraints, given the nature of the solution, the political environment etc. Then we can develop our initial plans based on that strategy.

One of the requirements of the standards is that the Support Case has to judge to what degree the customer’s requirements are being met. But it is essential that we go further than this, we first have to determine if those requirements are adequate, that they are comprehensive, that they are realistic (SMART) etc, and how do we do this?

Support Engineers know what the answer is, we do it by evaluating the processes by which the requirements were developed; in addition to taking cognisance of the operational requirement, did we take the trouble to understand the extant support infrastructure, did we address standardisation, did we gather and utilise historical data, did we collect collate and respond to Lessons Identified, did we identify the cost and the availability drivers, did we look to new technology that could improve the supportability of the Mission System and the effectiveness of the Support System? Did we understand and take cognisance of the operational environment, the weather, the terrain, the distances involved, the likely impact of enemy action on the target system or on the Lines of Communication?

If we did then the requirements will be sound and we will have provided a solid foundation for a Support Engineering programme that is set to succeed.

If we didn’t, then the whole Support Engineering edifice is built on foundations of sand and poor Availability and high Through Life Cost [TLC] are more or less guaranteed; unless radical (and inevitably expensive) action is taken.