Using Scenarios to Identify and Trade-off Dependability Objectives in Design. Georgios Despotou; The University of York; York YO10 5DD UK

Transcription

1 Using Scenarios to Identify and Trade-off Dependability Objectives in Design Georgios Despotou; The University of York; York YO10 5DD UK John McDermid; The University of York; York YO10 5DD UK Tim Kelly; The University of York; York YO10 5DD UK Keywords: dependability, dependability cases, design tradeoffs, scenarios, requirements elicitation, rationale capture, network centric warfare Abstract Whilst there is no consensus on the exact definition of dependability, many agree that it is a composite term consisting of many different non-orthogonal attributes. These can be in conflict or in harmony. This characteristic of dependability inevitably results in compromises and trade-offs being made during the design process. During the evolution of a dependable system, it is important that stakeholders justify any trade-offs made. These decisions must be made with due consideration of the system s operational role and context. Scenarios can be used to capture, in descriptive form, the different aspects and context of the system s operation. Stakeholders can use scenarios to describe their views of intended system operation. Elaborating on the scenarios, stakeholders can elicit specific and more detailed dependability objectives (e.g. relating to safety, performance and availability). By providing a clear context, scenarios allow system stakeholders to reason about the acceptable bounds for each dependability objective. In the design of the system it can be hard to satisfy the dependability objectives of all scenarios. An understanding of the importance of each scenario (as elicited from the stakeholders), together with the bounds associated with scenario dependability objectives, can be used to support the process of trading-off one objective in favour of another during design. In this paper we describe this scenario-based approach to the identification and balancing of dependability objectives in design. Introduction Increasingly, developers of large scale and complex systems are often challenged to argue the dependability of their systems during operation. Consequently, the concept of dependability cases has arisen. Dependability cases communicate a clear and defensible argument that a system is acceptably dependable within a certain operational context. Dependability is a composite system property consisting of heterogeneous and non-orthogonal attributes. From a more general standpoint dependability has been described as a variable sized vector of attributes describing subjective desiderata according to the stakeholders particular requirements (reference 1). Scenarios are a means commonly used to capture tacit information and the rationale for eliciting requirements, by considering the anticipated use of the system. During the evolution of a dependability argument, scenarios form the necessary context, based on which better judgements about the evolution of the argument can be made. The dependability objectives of a system can be in conflict or in harmony, according to how the system is designed, leading to inevitable situations where trade-offs must be made. When making trade-offs a dependability objective may not be fully, but instead met partially, in favour of addressing another objective of more importance to the system. Throughout the development of the system, such decisions must be justified and recorded capturing at the same time the rationale for the decision. The paper presents an approach that fits within the dependability case framework for identification and balancing of dependability objectives. An example of the approach is provided by creating the dependability argument for a hypothetical Battlefield Communications System, whilst making balanced design decisions.

2 Fundamentals of the Dependability Case Framework Dependability cases are based on proven and widely used concepts of safety cases. Safety cases communicate an argument that a system is acceptably safe in a particular context. Safety cases ultimately address only one attribute (safety), whereas dependability addresses more attributes such as availability, safety and security. Our previous work (reference 2) defined the dependability case as being a clear and defensible argument that a system is acceptably dependable in a certain operational context, and identified the problems that appear when creating a multi-attribute argument. At the core of the proposed framework is the Goal Structuring Notation (GSN), a graphical notation (adopted widely in the safety domain) used to evolve and record the dependability arguments. The GSN explicitly represents the individual elements of any argument (requirements, claims, evidence and context) and the relationships that exist between these elements. It is not the scope of the paper to present the GSN (which is presented in detail in reference 3), although due to the nomenclature used in GSN, the terms objective and goal are considered to be identical and have been used interchangeably. The attributes of dependability are heterogeneous, non-orthogonal and can be interrelated to each other. Attempting to address all dependability attributes can result in competing objectives. For example it is a common problem for availability to be in conflict with safety (e.g. in civil aviation). As a consequence there will be situations where it is inevitable that some dependability objectives must be traded-off in favour of others. For each attribute different methods, practices and expertise exist that result in different types of arguments supported by different types of evidence. Hence, an initial observation of the work was that presenting and arguing about all the individual (attribute) objectives of a system within a single argument is ineffective, as it is difficult to appreciate when an objective has been systematically and sufficiently addressed. In order to resolve the issue of the attribute heterogeneity we have adopted a modular approach to structuring dependability arguments. Creating different modules of arguments is a GSN capability, which has been so far used to manage complex safety cases. The safety case for an overall system can be divided into a number of modules containing the separate arguments and evidence for different aspects of the system s safety. Further description of modular and compositional safety cases can be found in reference 4. In the same vein, we create individual arguments for each of the dependability attributes, encapsulating the appropriate types of argument and evidence. Figure 1 provides an example of the layout of the different argument modules. On the top of the figure is the Top Level Dependability Argument module. This is an argument justifying that the dependability objectives elicited are appropriate for the system s use. Constructing the top-level dependability argument will result in defining specific dependability objectives, each referring to a dependability attribute. This gives Spinal Safety Argument us the ability to argue over each attribute individually that the system meets its objectives. Also it is worth noting that all the attribute modules are put forward in the context of a trade-off argument, which provides an argument that all attributes are acceptable in the context of each other. For example, the system is acceptably safe and at the same time acceptably secure and in the same time acceptably fast. The Battlefield Communications System (BCS) We consider the example of a Battlefield Communications System (BCS) designed to allow collaboration between the elements within a battlefield. Types of such elements include the theatre headquarters, mechanised units and infantry companies. Such systems are at the heart of Network Centric Warfare (NCW). NCW requires integration Spinal Top Level Dependability Argument Spinal Security Argument Context Trade -off Argument Figure1 - Modular View of Dependability Spinal Performance Argument

3 and coordination between all battle, control and decision making systems so that appropriate tactics and resources are used to achieve the mission goal (reference 5). Even at first glance the NCW paradigm demands a large number of communication links between the elements of the battlefield. This requires a communication infrastructure that can be used by all the elements that make up the overall battlefield system. Among the main services of the BCS are: analogue and digital voice services, data messaging and (battlefield) data sharing between the battlefield elements, and automatic unit position reporting and route planning. The BCS is a system that consists of many subsystems that are either functioning on their own right (e.g. network routers) or are integrated within other platforms (e.g. digital transmitters within vehicles). The BCS consists of a collection of systems including terminals, radios, digital encryption devices, antenna masts and microwave dishes. It is obvious that a system with such complexity and diversity of systems and technologies used can have different interpretations for dependable operation, especially in a military environment. Scenarios as a Means of Objectives Elicitation Figure 3 presents an example top-level dependability goal structure, which captures the principal goals to be addressed during the initial phase of the argument evolution. The top-level dependability goal can be as simple as dependable. The top-level dependability goal GD is stated in the context of the anticipated operational role of the system. Arguing over the anticipated scenarios of the system operation allows us to further decompose the goal taking into account the expected modes of operation of the system. In this example we have identified as possible scenarios within the operational role, the use of the BCS during a battlefield Search and Rescue (SR) mission, and the Routine Battlefield Reconnaissance. Scenarios can even be used to describe the qualities necessary for a scenario describing the disassembly and transportation of the BCS (e.g. ease of dismounting components). Our approach in defining the dependability objectives has its basis on identifying the behaviour of the system that is required, in order for it to achieve the scenarios that the stakeholders envision. In different situations the system may have to demonstrate that it achieves different dependability objectives. Scenarios provide an effective means for capturing information and presenting them in a structured form, so that they can be used methodically during the design and the evolution of the dependability argument. In the case of the BCS, scenarios are means of facilitating the stakeholders to describe and share discussions concerning the envisaged use of the system. We use scenarios to identify what the system is expected to do, to elicit any constraints and most importantly to identify the rationale underlying the application of the constraints (i.e. capturing the reasons why constraints are necessary). Scenarios are often referenced during the development of a dependability argument, as they provide the argument s context. G_SR GD dependable SGD Argument over anticipated scenarios dependable for a 'Search and Rescue' mission S_Roles System's operational role Scenarios System scenarios G_BR depdnable for 'Routine Battlefield Reconnaissance' Figure 2 Top Level Dependability Claim We have used two types of scenarios to define the operational context of the dependability argument; super-scenarios and micro-scenarios. Elicitation of both types of scenarios consists of several steps, the aim of which is to elicit the rationale for the top dependability argument. Super-scenarios are based on the concept of operations, and identify the overall use of the system with an aim to identify the attributes that the system should achieve in order to successfully accomplish the scenario. Micro-scenarios are inspired by work of the Software Engineering Institute (SEI) to elicit Quality Attribute requirements for software architectures (reference 6). Their main use is to elicit specific dependability requirements for the system, which in combination with the super-scenarios will provide clear and unambiguous dependability objectives for the system designers. In contrast to super-scenarios they are more attribute-oriented (rather than operational oriented), and they make explicit references to entities of the system (assets, sub-systems etc). The Search and Rescue (SR) mission and the Routine Battlefield Reconnaissance are two of the possible anticipated scenarios. Out of the two, the SR scenario will be used to illustrate further development of the top-level dependability claim based on the application of scenarios.

4 Table 1 shows the steps for eliciting the super-scenario as well as the purpose of each step and an example of the BCS Search and Rescue scenario. Each of the steps has a contribution in facilitating the creation of the dependability argument, as it is described in the middle column of the table. Table 1 Super Scenario Steps S - Scenario Steps Purpose/Outcome BCS Example 1) State participant stakeholders. Identification of the stakeholders involved/affected by the scenario. Rescue team, people/entities to be collected, mission commander. 2) Describe end objective of the Helps identify when a scenario will Deployment of a team within a scenario. be successful. radius of 100km in a possibly hostile environment, trace, recovery and safe return with the object(s). 3) Identify utility of the scenario. Description of what is the benefit for introducing the scenario to the system. 4) Describe participant top-level system functions. 5) Identify constraints on scenario and functions. Highlights the motive for the scenario. Together with step 2 helps capturing the rationale for eliciting the acceptability criteria for the dependability goals. Associates the system operation with the mission (end-objective). Helps identify the concept of the system. Capture of the rationale of the constraints with respect to the mission/scenario objectives. Rescue of life or recovery of an object of great importance. Combined losses lees than if the mission would not take place. Deployment Start-up - Update of digital map - Team location update Command Mission state update Transmission of data. Rescue team should be sent ASAP to maximise chances of the object s survival. All communications should not be done in a way that the team s location can be traced by enemy. System should be operational within a 100 km radius. As show in table 1, the scenario engages the stakeholders to define the operational context of the scenario and elicit the required attributes. For example when describing the end objective of the scenario, the stakeholders identify the radius (performance objective) within which the system needs to operate. Furthermore, by describing the utility of the scenario we can understand that if the number of anticipated SR team casualties is more than the lives saved, this may be considered unacceptable. Certainly there are occasions when such decisions will have to be made by subjective judgement. For example, when the SR team needs to collect an object of great importance. Whereas in the former case the decision could be based on a comparison between the expected losses against the lives to be saved, in the latter there cannot be a straightforward comparison. The justification for accepting the mission risk depends solely on the importance of the object to the stakeholders involved. The description of the end objective in combination with the identification of utility reveals further objectives such as the requirement that the SR team cannot be traced easily. Identification of the operational context, taking into account the functions of the system that will be used during the scenario, allows us to determine more detailed objectives. For example we conclude that since the SR team will use the BCS to transmit its location, this should be done with acceptable security so that enemy units cannot discover the team s location. Following the conclusions from defining the super scenario (table 1) we can further decompose the G_SR goal, by adopting the strategy of arguing over the attributes that are required for the scenario to complete. As such, possible sub-goals denote that the system should be acceptably secure, safe and available (Figure 4). However, only identifying the overall properties that the system should demonstrate during operation, is not enough to evolve a clear dependability argument. Micro-scenarios are employed to elicit further detail for each attribute of concern, by describing the specific behaviour the system should demonstrate with respect to each attribute. Table 2 presents the steps of a micro-scenario concerned with the availability attribute that was previously identified for the search and rescue (SR) scenario of the BCS.

5 Table 2 Micro-scenario Steps µ Scenario Steps Purpose/Outcome BCS Example 1) Identify stimulus. Identification of a trigger for the attribute, which needs to be considered when it arrives at the system. Failure of systems providing necessary functions for SR scenario. 2) Identify operational context of stimulus. 3) Categorise µ scenarios according to S-scenarios. Relates to S-scenario by examining the impact of the stimulus on the scenario. Provides more specific grounds for targets and limits. Identification of the attribute (different attribute possibly means different type of argument and evidence) as described by the S- scenario. Facilitates the elicitation of argument strategies. Identify goals descending from different scenarios but refer to the same attribute. 4) Identify appropriate response. Mitigation of the effect, maintaining the operational objectives. 5) State impact of scenario on the system. Indicate what are the effects of the scenario on the system. Brainstorming for designers. SR team must be able to communicate when required as it may be critical. All critical services during the mission should be available to the team. Maintain provision of service, discover different source for the same service. Additional resources and systems required to replace the ones failed. Micro-scenarios provide the way forward for the argument. Strategies SAvail and SSafe (in figure 4) are based on the description of the micro-scenarios, since both make arguments over the different stimuli (for each attribute) for this system. Thus, for safety the argument is made over the identified situations leading to loss of life and for availability over the identified situations leading to service disruption, resulting in the goals SerAvail and TimelyDeployment shown in Figure 4. It is worth noting that one of the identified situations in the micro-scenario that can lead to loss of life (safety), is concerned with the timely operation of the system. Therefore, a safety concern about the operation of the system in the particular context (SR Scenario) resulted in a performance objective, something that without the use of the scenarios may not have been explicitly identified. Furthermore, GSN provides traceability, making it easier to follow the argument to its origin and find the rationale for any goals/decisions throughout its development. Following the argument we can see that the for the SR scenario (which has been referenced as context), it is important that the SR team can be deployed quickly. Example values for this goal are one hour, but under no circumstances should the system take more than two hours to be ready to support the SR team. Passing the limit value of acceptability for the timely performance objective means that the risk the SR team itself is exposed to, is greater than the probability of actually coming back with more survivors than possible losses. Therefore the deployment performance of the system cannot successfully satisfy the requirements for the SR scenario. The creation of a dependability case is a process that takes place in parallel with the design, recording any design assumptions and conclusions made during the construction of the argument. Scenarios provide a means of eliciting the rationale needed for creating a system s top-level dependability argument. Starting from a general dependability goal, scenarios offer the necessary context for refining the goal into specific objectives and specifying the context for their acceptability (target and limit criteria). In order to effectively incorporate these criteria within the argument GSN structure we have introduced the target and limit symbols, which also provide a context in which trade-offs can be discussed. Those additions to GSN are discussed in the following section.

6 G_SR dependable for 'Search and Rescue' scenario S_GR Argument over attributes of concern Sc_Attr Attributes of concern in scenarios G_Att_Sec secure for SR mission G_Att_Avail available for SR mission G_Att_Safe safe for SR mission C_AvailRisk SAvail SSafe C_SafeRisk Causes of communications Argument over situations of service disruption Argument over situations leading to loss of life People at risk SerAvail TimelyDeployment Disruption of critical services has been addressed Simulation of not deploying the system in timely manner has been addressed SRScenario SSerAvail STimelyDeployment SysFuncAlloc Definition of SR mission critical services Argument over availability of critical services Argument over deployment (time) characteristics of the involved systems System participating during the SR mission TargetPickLocAvail TargetSysDeploy Service should be 100% available for the duration of the mission LimitPickLocAvail Service should not be disrupted for more than 5 mins PickLocServAvail 'Pick up location' services are acceptably available SysDeploy All involved systems are operational in a timely manner Operational within 1 hr from notfication of mission LimitSysDeploy Operational within 2hrs from notification Figure 4 Top Level Dependability Argument

7 Capturing Targets and Limits within the Dependability Case It is common that systems for which developers are required to provide assurance of their dependable operation are by their nature complex in structure and are often deployed in complex and dynamic operational environments. An eventuality that almost certainly appears in the construction of systems of such scale is that a design will not achieve all its dependability objectives in their entirety, resulting in trade-offs between the dependability objectives. A concept introduced to facilitate trade-off is the definition of the bounds of compromise for each dependability objective, by identifying its acceptability criteria. When identifying a dependability objective, we implicitly identify a target requirement that the system should satisfy. For example consider the typical requirement of 99.9% percent availability. For this target requirement the defined dependability objective would be a system of acceptable availability, with an acceptability criterion of 99.9% of the total operational time. The Top Level Dependability Argument includes justification of the target criterion associated with a dependability goal, which is set according to the operational needs of the system. Apart from the target acceptability criterion we also define the limit of acceptability. We define the limit as being the minimum condition that must be met so that the system will acceptably satisfy the objectives of the anticipated operation (scenarios). Targets and limits in combination define the bounds within which we can trade an objective in favour of another resulting in an overall acceptable system. The amount by which the target and limit differ is a decision of the stakeholders involved that will eventually determine the region within which we can trade an objective. For example, for a critical scenario the limit may be close to the target allowing less flexibility. The concept is similar to the ALARP principle, used in the safety domain, as a means of trading-off safety against cost. ALARP defines the tolerable risk as the risk where additional spending on risk reduction would be in disproportion to the actual obtainable reduction of risk (reference 7). A risk target after which the risk is unacceptable for the system describes what is meant by tolerable risk. The concept of the bounds has been introduced in GSN, presented as the context symbol with a bar on the top or bottom indicating whether it s a target or limit respectively. Figure 4 shows an example of the notation by presenting a performance objective of the BCS with its associated acceptability criteria. Design Alternatives and Dependability Goals So far we have discussed how scenarios can be used to elicit dependability objectives and support development of the dependability argument. Looking now at system development from a designer s perspective we will demonstrate how the development process of the system interacts with the development of the argument. So far the top-level dependability argument provided the objectives required to be met by the system. At the same time construction of the argument requires references to design decisions, such as the definition of the top-level functions, perceived conceptual design (identification of platforms Figure5) and the allocation of functions to each of the platforms and subsystems. After this stage, explicit decisions need to be made about the design of the system. According to what are the specified objectives, designers can employ a number of methods to define possible designs. Elicitation of designs is not within the scope of the paper, but we acknowledge that during every design decision designers may be faced with the challenge of selecting between several possible design alternatives. Each of the design alternatives features different characteristics that might have different impact on the dependability objectives. Balancing these objectives is a subjective and qualitative decision, which needs to be done by assessing the importance of each of the objectives for the system, and assessing each alternative with respect to the objectives. Considering the BCS example, for reasons of simplicity we define two main platforms being: a) the base headquarters (HQ) and b) the SR team. Figure 6 shows the subsystems that each of the two main platforms comprises of. Based on this information, we define two possible design alternatives in the context of goals/objectives SysDeploy and PickLocServAvail (Figure 4). The former refers to the timely deployment of the BCS so that it can support the SR mission within one hour from notification. The latter refers to the availability of the BCS service that allows the SR team to request the HQ to be picked up by providing the pick up location. Both goals have been defined in the context of a target and a limit that have been elicited using the scenarios.

8 HQ - Terminals - DSP module - Network connection - Network router - Antenna mast RF SR-Team - Receiver - Signal Processing - Positioning module - Terminal Alt 1: Redundant design by duplicating all services. Alt 2: Redundant critical services. Use of hot stand-by components. Figure 5 Overview of the BCS systems As it is depicted in figure 5 two alternatives have been considered each with a bias to the two identified goals. Alternative 1 provides redundancy by duplicating every service and with that all the systems that provide the services. This would require additional systems on both platforms (HQ and SR Team). At a first glance it is noticeable that alternative 1 has a very positive impact on the availability objective PickLocServAvail. Providing additional systems that have the same functionality will make a more available system than without redundancy, as it reduces the probability of loss of service due to both systems failing simultaneously. However, the decision to provide redundancy for all services consequently increases the total number of systems participating and therefore increases the time the BCS will need to deploy and set-up for operation. The effect becomes greater when considering the start-up (system and personnel) procedures and the overhead due to the synchronisation of the extra sub-systems. On the other hand, Alternative 2 does not provide redundancy for all services but instead focuses on those that are considered to be the most critical, and for the rest uses systems that can be replaced very easily (e.g. a plug-in rack for the DS Processor). Alternative 2 has an obvious negative impact on objective PickLocServAvail since there may be a disruption of service for a few minutes where the service is provided by a single system. Nevertheless, it has a positive impact on SysDeploy as there are fewer systems to deploy, and the stand-by systems can be positioned immediately after the BCS has started operating, utilising better the personnel that will set-up the BCS. The two alternatives have their relative advantages and disadvantages. The contrast between the two alternatives can be seen when trying to evaluate them against the dependability objectives. In order to make a decision, we need to take into account the context of the goals as identified by the scenarios. Although the final decision is subject to the stakeholders it is important to recognise that this decision has to be justified by an argument. This stage is another instance where scenarios can be usefully utilised to help making the decision. In this example, alternative 2 was selected. The justification for the selection resides in the scenarios. Losing the service for five minutes will have less risk of failing the mission than starting from the beginning with a considerable delay. We assume that both alternatives are within the limits of acceptability. If they were not, then the system would fail to successfully demonstrate acceptable behaviour for the anticipated SR scenario. Still, there is a possibility that the stakeholders may reach an impasse if the design cannot meet its objectives, eventually leading to acceptance of the system as it is. Such a case implies that bounds defining the acceptability are automatically re-evaluated. Although it was clear in the above example as to why the final design decision was made, when a system has to satisfy more dependability objectives decisions will often be less straightforward requiring a systematic process for making and arguing the necessary trade-offs. The authors have defined such a process that can be used within the dependability case framework. However it is outside the scope of the paper to present it. Even though the BCS is a hypothetical system, it is not far from reality. The scenario-based approach gave the required input to make the appropriate trade-off(s) and select the most suitable design. Summary Dependability is a composite term consisting of many different non-orthogonal attributes, which can be in conflict or in harmony. This results in trade-offs that need to be made but also justified by the system stakeholders. Dependability cases, building on the existing well-established concept of safety cases must communicate the argument that a system is acceptably dependable for its operation. In this paper we present an approach based on scenarios to construct and evolve a dependability argument using GSN, eliciting the dependability objectives for the

9 system and justifying reconciliations between conflicting dependability objectives. Goal Structuring Notation provides a useful tool for explicitly identifying and tracing the rationale (that underlies every design decision). Defining scenarios that assist the elicitation of the dependability argument is proving to be a propitious means for constructing a dependability case. References 1. Prasad D., Dependable Systems Integration using Measurement Theory and Decision Analysis. PhD Thesis, Department of Computer Science, University of York, UK, Despotou G., Kelly T., Extending the Safety Case Concept to Address Dependability. In proceedings of the 22 nd International System Safety Conference, System Safety Society, Kelly T. P., Arguing Safety A Systematic Approach to Managing Safety Cases. PhD Thesis, Department of Computer Science, University of York, UK, Kelly T., Managing Complex Safety Cases. In Proceedings of the 11 th Safety Critical Systems Symposium, Springer-Verlag, Network Centric Warfare. Department of Defence Report to US Congress ( 6. Bass L., Clements P., Kazman R., Software Architecture in Practice 2 nd Edition. pp Addison-Wesley (ISBN: ), International Electrotechnical Commission. IEC Functional Safety of Electrical/ Electronic/ Programmable Electronic Safety Related Systems. IEC Biographies Georgios Despotou BEng (Hons), MSc, MIEE. Research Student, Department of Computer Science, The University of York, York, YO10 5DD, United Kingdom. Phone: , Fax: georgios.despotou@cs.york.ac.uk Georgios Despotou is a research student in the high integrity systems engineering (HISE) group, under the defence and aerospace research partnership (DARP). He received a BEng (Hons) in the joint degree of Computer Systems Engineering from the University of Hull in 2001 and in 2003, a Masters of Science in Software Engineering from the University of York, where he is currently a PhD student. Current research activities involve Dependability Cases and software and systems architectures for high assurance systems. Prof. J.A. McDermid, Ph.D. Professor of Software Engineering, Department of Computer Science, The University of York, York, YO10 5DD, United Kingdom, Phone: , Fax: john.mcdermid@cs.york.ac.uk Prof. John McDermid has been Professor of Software Engineering at the University of York since 1987 where he runs the High Integrity Systems Engineering group. HISE studies a broad range of issues in systems, software and safety engineering, and works closely with the UK aerospace industry. Professor McDermid is the Director of the Rolls-Royce funded University Technology Centre (UTC) in Systems and Software Engineering and the BAE SYSTEMS-funded Dependable Computing System Centre (DCSC). He is author or editor of six books, and has published about 280 papers.

10 Dr Tim Kelly MA, PhD. Lecturer, Department of Computer Science, The University of York, York, YO10 5DD, United Kingdom. Phone: , Fax: Dr Tim Kelly is a Lecturer in software and safety engineering within the Department of Computer Science at the University of York. He is also Deputy Director of the Rolls-Royce Systems and Software Engineering University Technology Centre (UTC) at York. His expertise lies predominantly in the areas of safety case development and management. His doctoral research focussed upon safety argument presentation, maintenance, and reuse using the Goal Structuring Notation (GSN). Tim has provided extensive consultative and facilitative support in the production of acceptable safety cases for companies from the medical, aerospace, railways and power generation sectors. Before commencing his work in the field of safety engineering, Tim graduated with first class honours in Computer Science from the University of Cambridge. He has published a number of papers on safety case development in international journals and conferences and has been an invited panel speaker on software safety issues.