Safety Analysis of Software Architectures Lightweight PSSA

Transcription

1 Safety Analysis of Software Architectures Lightweight PSSA O. Lisagor; Department of Computer Science, The University of York; York, UK Prof. J. A. McDermid; Department of Computer Science, The University of York; York, UK Dr. D. J. Pumfrey; Department of Computer Science, The University of York; York, UK Keywords: preliminary system safety assessment, lightweight safety assessment, software architecture analysis Abstract Several safety standards include system architecture analysis as an explicit stage in the safety process. For example, both the Aerospace Recommended Practices (ARP) 4754 & 4761, and the EUROCONTROL Safety Methodology include Preliminary System Safety Analysis (PSSA). PSSA provides an early assessment of the credibility of a proposed system architecture, reducing the risk that safety problems are uncovered late in the life cycle where they are expensive to rectify. Existing guidelines on conducting PSSA generally include the construction of Fault Trees to assess the safety properties of the proposed architecture. This has several problems including cost, difficulty of identifying common mode failures, and so on. Also, experience has shown that development organisations face great difficulties in conducting this relatively formal analysis on "early draft" design proposals. These concerns demonstrate a need for a less formal PSSA-enabling assessment we call it "Lightweight PSSA". This "Lightweight PSSA" must allow assessment of immature architecture proposals in a cost-effective manner. It must provide developers with a greater understanding of the safety implications of a proposed architecture, and must produce artefacts that will facilitate later, more stringent, PSSA. Introduction The civil aerospace safety assessment and certification guidelines ARP 4754 (ref. 1) and 4761 (ref. 2) set out requirements for the system safety process as applied to aircraft (and engines). This process explicitly identifies Preliminary System Safety Assessment (PSSA): a systematic examination of a proposed system architecture(s) to determine how failures can lead to functional hazards identified by the Functional Hazard Assessment (FHA), and how the FHA requirements can be met (ref. 2). PSSA is a project risk-reduction phase that is meant to reduce the likelihood of safety problems being discovered belatedly. Clearly, in order to fulfil its role, and influence the design, PSSA should be undertaken early before the design stabilises. However, Fault Tree-based PSSA described in the ARPs seems to be too labour-intensive for early immature design proposals, when a number of re-design and re-analysis iterations are likely to be necessary. This conflict was identified previously (ref. 3) along with a need for a lightweight way of doing PSSA at an early stage in the design process. This paper presents a method for a less formal PSSA-enabling analysis we call it Lightweight PSSA. This method provides developers with a greater understanding of the safety implications of a proposed architecture; it also produces artefacts that will facilitate later, more stringent, PSSA. Our method builds upon research in the software architecture and software safety communities, and draws from the concepts of Software Architecture Views (ref. 4), some established scenario-based software architecture analysis methods (ref. 5 6) and SHARD (ref. 7) a HAZOP-inspired software analysis method. Another idea that underlies our research is our belief in the benefits of separating safety-related modelling from analysis. We believe that such separation will improve traceability from analysis artefacts to design (and vice versa) and will provide extra assurance in the completeness of the analysis. It should also facilitate reuse of some safety analysis (or, more precisely safety-related modelling) artefacts in the context of design modifications and/or reuse. Although this paper describes a "Lightweight PSSA" method for Software Architectures an area where the inadequacy of the ARP guidelines has been previously identified (e.g. see reference 8) it can be extended beyond software considerations.

2 The method we propose consists of three phases: dependency modelling, deductive (exploratory) analysis and inductive (verification) analysis. In the first phase two views (we call them Forward and Backward Dependency Views) of the architecture are constructed to capture information about dependencies between services of different modules of the architecture. For application software we define service as the delivery of an item of data, or the execution of a process communication or synchronisation activity, at a specific time. The two dependency views are then used in the analysis phases of the assessment, thus forming an insulation layer between analysis and specific design notation or irrelevant design information. The goal of the deductive analysis phase of the assessment is to establish (and analyse) potentially hazardous chains of dependencies in the architecture. These chains are identified by considering hazards (identified at earlier stages of the safety process), specifying them in terms of the services that modules provide, and then walking through the views in order to establish all the dependencies of critical services, as well as any mechanisms that minimise these dependencies. Finally, in the third, inductive analysis, phase of assessment, hypothetical failures of some key modules services are considered and their potential effects on the system as a whole are established. Therefore, the purpose of this phase is to verify both the completeness (in terms of hazardous dependency chains identified) and correctness (especially with respect to potential single causes of failure) of the deductive analysis. Overall, the three phases of our method divide the assessment into manageable incremental tasks; each phase provides analysts with better understanding of the safety implications of the proposed software architecture and allows them to verify (at least to some degree) the results of the previous phase (the first, modelling, phase verifies completeness and clarity of the architecture description). The remainder of this paper describes the proposed method step-by-step using, for illustrative purposes, the software architecture of a hypothetical embedded control system. Example We describe the application of our Lightweight PSSA method to the software architecture of a hypothetical missile system. The example was developed by MBDA and has been previously used as a case study by P. A. Lindsay and one of the authors (ref 9). Unfortunately, space limitations do not allow us to describe the system in much detail; we refer readers to the above paper for a more complete description of the system, its context and design. The system concerned is the Electronics Unit (EU) of a simplified hypothetical Long Range Air-To-Air Missile (LRAAM). The primary function of the EU is implementation of control laws it takes inputs from the Inertial Management Unit (IMU) and provides its outputs to actuators (missile fins). In addition to this primary role, the EU manages communications with the launch vehicle and can block ignition of the missile s motor by activating the Firing Interlock (although once launch vehicle s Stores Management System successfully ignites the motor, the EU loses any control over ignition). The EU is a multi-modal system and its top-level modes include: PowerUpCheck, PreLaunch, Launch, Flight, Acquisition and Terminal. In our example, we only consider the PreLaunch mode and transition into the Launch mode. PreLaunch is effectively an initialisation stage (with software system checks); in the Launch mode the motor is ignited and missile (ideally) flies clear of the launch vehicle. Figure 1 presents part of the software architecture of the EU in Real-Time Networks (RTN) Notation (ref. 10). RTN has been derived from the Modular Approach to Software Construction and Test (MASCOT) methodology (ref. 11). The RTN architecture diagram identifies interfaces with other systems (IMU,, Actuators and the Firing Interlock), EU components (e.g. Mode Control, Inertial Navigation, Separation Autopilot, etc) and communications between these components. Communications are further characterised by the protocols symbols (see figure 2 for the key). Table 1 lists some of the (simplified) hazards identified during FHA for the case study system.

3 Mode Control Mode Mode Events Interlock Handler Firing Interlock clk4 Stop Firing IMU clk1 Inertial Navigation Separation Autopilot Actuators Body Motion Missile State Missile State Actuator Demands clk2 Target Read Messages Messages In INS Data Transfer Alignment INS Initial Messages Out clk3 Write Messages Missile Status Summary Missile Ident Status Reporting Status Reports Manage BIT Figure 1 Software architecture (partial) for EU Active Components READER / WRITER Activity I/O Interface Subsystem Destructive Writing (Writer cannot be held up) Non-Destructive Writing (Writer can be held up) Basic Interaction Protocols Destructive Reading (Reader can be held up) Signal (Event data) Channel (Message data) Figure 2 Key to Real Time Networks (RTN) notation Non-destructive Reading (Reader cannot be held up) Pool (Reference data) Constant (Configuration data) Denotes VOID DATA protocols (e.g. stimulus) UPhase 1 Dependency Modelling During this phase, analysts consider an architecture description and construct safety-related models (called Forward and Backward Dependency Views) that will be used for further analysis. The purpose of introducing an explicit safety-related modelling phase into the assessment is threefold: To provide an insulation layer between further analysis and notation-specific or irrelevant details of design To help to identify incompleteness (from the safety view point ) of architecture description

4 To facilitate reuse: Dependency Views are independent of the particular context/environment of the system (including particular hazards inherent to the system in this context) and they are more resilient to changes in the design (i.e. effect of local changes in the design domain will remain local in dependency views). They may also facilitate analyses with the respect to other quality attributes of an architecture (e.g. reliability). Table 1 Hazards ID Hazard Description Effect Classification H1 Missile fails to fly clear of the launch vehicle Missile hits the launch vehicle Catastrophic H2 Missile locks on to the launch aircraft Missile hits the launch vehicle Catastrophic H3 Missile locks on to the wrong target Missile hits the wrong target (collateral damage) Catastrophic H4 Actuators (fins) are not controlled Missile hits the wrong target or the launch vehicle Catastrophic H5 Actuators controlled in a faulty fashion As above Catastrophic H6 Missile launched in presence of faults (unsafe launch) As above Catastrophic H7 Missile not launched despite no failure Negligible (safety). Up to Mission not accomplished in driving component catastrophic in mission context. H8 Missile not launched due to correctly detected failure As above As above H9 Inadvertent launch Collateral damage Catastrophic UStep 1-1 Identification of architecture modules and services:u We start modelling by considering the proposed architecture and compiling a list of all modules it identifies, along with a list of all services each module provides (and a description of each service). Identification of software architecture modules in the LRAAM example is a straightforward task, as each activity in figure 1 is effectively a module. In addition to this, the data interfaces shown on the diagram were also listed as interface modules. This yielded a total of 19 modules: Mode Control, Interlock Handler, Inertial Navigation, Separation Autopilot, Read Messages, Transfer Alignment, Manage BIT, Status Reporting, Write Messages,, Inertial Navigation, Firing Interlock, Actuators, Target, Initial, INS, Missile Ident and 2 Clock modules (Clk3 and Clk4). Services identified for these modules generally corresponded to the data flows out of module. For example, the Inertial Navigation activity interacts with Transfer Alignment and Separation Autopilot by providing Missile State data, and with Mode Control by reporting Mode Events. From these interactions, two services have been identified: Calculate ( Calculate physical missile state ) and Report ( Report if body motion data received is out of range ). However, in a number of modules, some services were not quite that obvious. For example for Separation Autopilot three services were identified: Demand ( Calculate actuator demands for the launch mode only), On ( Switch-on on the transition into the launch mode ) and Off ( Switch-off on the transition out of the launch mode ). Another interesting example is the Mode Control module: apart from rather obvious Mode service ( Calculate system mode based on mode events received ), consideration of the interaction protocol for receipt of Mode Events (a channel protocol that, in order to prevent data loss, locks writer processes until the reader consumes the data item) led us to identify an extra service the module provides Release ( Release mode events generators ). UStep 1-2 Determination of failure modes and service characteristics:u In this step, analysts apply a set of HAZOPlike keywords to each service of each module in order to identify failure modes of these services. These failure modes are then grouped into a small number of key service characteristics. For application software, the keywords used are the same as in SHARD, and the key service characteristics would normally include some or all of: Timing, Occurrence and/or Value. Table 2 shows the services, characteristics and failure modes identified for the Mode Control module (the complete service characterisation table for the software architecture had over 120 failure mode entries).

5 Table 2 Modules / Services characterisation table (partial) Module Service Service Description Characteristic Failure Mode Notes Mode Control Mode Value FalseAbandon FalseLaunch FalseFreeFlight Release Calculate (and command ) system modes based on mode events received. Occurrence InvalidValue OmitAbandon OmitLaunch OmitFreeFlight Respective wrong mode commanded Respective appropriate mode is not commanded Mode commanded more Comission than once Timing LateAbandon Respective appropriate LateLaunch mode commanded LateFreeFlight later than intended Release writer(s) of mode Occurrence Omission Writer not released events Timing Late Writer released late It is important to note that there is no single right way of characterising services provided by a module there are several potentially appropriate (and valid) service characteristic and failure mode classification schemes. Step 1-3 Construction of the Backward Dependency View: This is a graph-like view, in which the nodes correspond to architecture modules and edges correspond to the dependencies of characteristics of services of modules upon other modules. Each node bears a list of services identified for the corresponding module. Each edge is directed; informally, the question asked along the direction of the edge is what characteristics of which of my services depend on you? Thus, edges are marked by a list of services and their characteristics (in the form of <Service>.<Characteristic>). Figure 3 presents the Backward Dependency View for the LRAAM Electronics Unit. Although dependencies between the modules can be considered in any order, as far as the backward dependency view is concerned, it is more intuitive to proceed from software (or system/subsystem) inputs to outputs. It is possible that modelling will uncover errors or inconsistencies in the services characterisation schema (or indeed in lists of services themselves). This is a useful side-effect of modelling, and gives confidence in the models; if major flaws are uncovered, analysts will have to return to Step 1-2. Step 1-4 Construction of the Forward Dependency View: The semantics of this view are similar to the backward dependency view described above, except that the question asked along the edges is: what characteristics of my service do you depend on? Thus, it is expected that wherever a link between two modules exists in the backward dependency view, a link (in the opposite direction) will exist in the forward dependency view (and vice-versa). Figure 4 illustrates the Forward Dependency view for part of the LRAAM architecture. Phase 2 Deductive Analysis In this phase of the assessment the analysts traverse dependencies in the two views in order to establish and consider potentially hazardous chains of dependencies. The analysis starts by revisiting hazards identified earlier in the safety process (e.g. during the FHA stage). Each hazard is then re-stated in terms of critical dependencies upon service characteristics of appropriate interface modules. Adopting ATAM & SAAM terminology (ref 6) we call such rephrased hazard specification Scenarios, although readers not familiar with these analysis methods may find this term unintuitive.

6 Release.Tm Mode.* Data. [Oc, Tm] Mode. [Oc, Tm] Target. [Oc, Tm] Inertial Measurement Unit - Data: Provide data characterizing the missile body motion Mode Control - Mode: Calculate Mode based on Mode Events received - Release: Release generator(s) of Mode Events On.[Tm, Oc] Off.[Tm, Oc] Demand.* Calculate.* Report.[Tm, Oc] Calculate.Tm, Oc] Report.[Tm, Oc] Release.Tm Mode.* Inertial Navigation - Calculate: Calculate physical missile state - Report: Report if Body Motion data is out of range (faulty) Clock (clk4) - Invoke: Issue Invocation signals for Interlock Handler at appropriate intervals Demand.* Separation Autopilot - Demand: Calculate actuator demands (launch mode only) - On: Switch-on on transition into launch mode - Off: Switch-off on transition from launch mode Demand. [Tm, Oc] Interlock Handler - Demand: Issue interlock demand on transition into the Abandon mode Control.* Control.* Actuators - Control: Control actuators (fins) Firing Interlock - Control: Control hardware Interlock Release.Tm Mode.* Report. [Oc, Tm] Data. [Oc,Tm] Target Val * - Data: Generate messages for Missile with pre-launch data - Mode: Generate messages requesting mode change (based on messages receive from the missile) Read A/c Messages - Data: Obtain/Forward INS Data from messages - Mode: Obtain/Forward mode requested by aircraft from messages - Target: Obtain/Forward initial Target from messages Mode.* Report.Val Data.* Report.* Write A/c Messages - Message: Compile messages to the aircraft from Missile Status Summary available Transfer Alignment - Report: Report the result of comparison of INS data calculated on missile and obtained from the aircraft - Data: Register INS data Message.[Val, Tm] Val Status.* Val Status Reporting Initial INS - Status: Compile Missile Status Summary from status reports received Status.* Backward dependency view Notionally passive (data) components not explicitly modeled Question along the arrow: What characteristics of my service depend on you? Key: Tm - Timing of service Oc - Occurrence of service Val - Value of service Manage BIT - Report: Report BIT result (status report) Missile Ident - Station: ID of missile s station Message.Val Message. [Tm, Oc] Clock (clk3) - Invoke: Issue Invocation signals for Writer at appropriate intervals Figure 3 Backward Dependency View of the (partial) software architecture of the EU After deductive scenarios have been formed, they are used by the team for walking through the dependency view of the architecture (backward search) to determine how modules can contribute to the successful execution of the scenario, what protective measures are designed into the proposed architecture and what measures could be incorporated at the later stages of design. Step 2-1 Specification of hazards as deductive scenarios: The first step of analysis is to specify hazards identified in FHA in terms of architecture modules and characteristics of their services. To illustrate this, consider the catastrophic hazard H1 ( Missile fails to fly clear of the launch vehicle ) identified for Electronic Unit of LRAAM (Table 1). This hazard was translated into the following scenarios: DS1.1: Separation Autopilot fails to switch on, or Separation Autopilot switches on too late DS1.2: Separation Autopilot issues wrong actuator demands, issues demands too late, or fails to issue demands DS1.3: Separation Autopilot switches off too early, or switches off unduly Note that, in order to improve traceability between the FHA and Lightweight PSSA, each scenario was given a unique ID that included the ID of the corresponding hazard.

7 Mode.* Mode Control - Mode - Release Clock (clk4) - Invoke Invoke.[Oc, Tm] Report.* Release. [Oc, Tm] Release. [Oc,Tm] Mode.* Report.* Release.[Tm, Oc] Interlock Handler - Demand Demand.* Firing Interlock - Control Inertial Measurement Unit - Data Data.* Inertial Navigation - Calculate - Report Calculate.* Separation Autopilot - Demand - On - Off Off.[Tm, Oc] On.[Tm, Oc] Demand.* Actuators - Control Target - Data - Mode Target.* * Message.* Read A/c Messages - Data - Mode - Target Write A/c Messages - Message Missile Ident - Station Calculate.* Data.* Status.* Transfer Alignment - Report - Data Report.* Status Reporting - Status Station.Val Invoke. [Tm, Oc] Report.* Data.* Data.* Manage BIT - Report Clock (clk3) - Invoke Initial INS Forward dependency view Notionally passive (data) components not explicitly modeled Question along the arrow: What characteristics of my service you depend on? Key: Tm - Timing of service Oc - Occurrence of service Val - Value of service * = Val, Oc, Tm Figure 4 - Forward Dependency View of the (partial) software architecture of EU Finally, it is important to point out that, as each scenario describes a sufficient combination of failures of interface modules, multiple scenarios can map into a single hazard. UStep 2-2 Execution of deductive scenarios:u In this step each scenario is considered individually, and deductive analysis is performed (this is similar to FTA). First, for each service characteristic that is critical for a scenario, the causes of failure internal to the module have to be considered: The validity of such causes should be agreed upon. The possibility of adding fault-detection or tolerance mechanisms within the module should be considered (along with the difficulty of designing and implementing such features). Appropriate forms of analysis that can be used to assure that the failure will not occur have to be established. For software these analyses can for example include proof of correctness, WCET analysis, particular forms of testing, etc. Second, for each critical characteristic, failures due to module dependencies have to be considered. The backward dependency view is used to identify other modules that are depended upon; the forward dependency view is used to identify which services and service characteristics of these modules should be investigated further. At the same time, any architectural mechanisms that minimise the strength of the dependency (such as redundancy, monitoring, etc.) are identified, their significance agreed upon, and documented. This step is repeated for each service characteristic found. For example, when considering scenario DS1.2, we established that, as all characteristics of Separation_Autopilot. Demand service are critical, so are the characteristics of Inertial_Navigation.Calculate and in turn IMU.Data services. As far as this propagation path is concerned, some mitigation mechanisms have been envisioned: the Inertial Navigation module performs out of range checks on IMU data (thus providing some mitigation against Value failures of of IMU.Data); also, prior to missile launch, data calculated by the Inertial Navigation module itself is compared to data calculated by systems, thus providing some assurance that Value and Occurrence characteristics (and, to a lesser extent, timing characteristic) of IMU.Data and Inertial Navigation.Calculate services

8 are adequate. However, this cross check is only performed prior to the transition to the Launch mode; failure of either IMU or of the Inertial Navigation module manifested after launch will lead to the hazard. Another (less intuitive) way of executing scenario DS1.2 arises from the dependence of timing and occurrence characteristics of Inertial_Navigation.Calculate upon characteristics of the Mode_Control.Release service. Our analysis showed, however, that the safety implications of this dependence can be minimised by careful design of these modules and their communication, e.g. through the appropriate use of time-outs. Overall, as far as DS1.2 is concerned, although some (indirect) architecture mitigation mechanisms are present, and some dependencies can be reduced at later stages of the design, it is important to note that a single failure in IMU, Inertial Navigation or Separation Autopilot modules may be sufficient for successful execution of this potentially catastrophic scenario. Returning to the description of the method in general, all service characteristics that were found to contribute to execution of a particular scenario should be marked with that scenario s identifier. If a situation arises where a particular service characteristic is already marked with the same identifier (i.e. it contributes to scenario execution more than once) this has to be noted explicitly. This footprint of execution of deductive scenarios provides an insight into the distribution of safety responsibilities across components of the architecture. It will be used in the inductive analysis phase of the assessment in order to select appropriate services of modules for further analysis. UPhase 3 Inductive (Follow-up and Verification) Analysis The primary role of this phase of assessment is to verify the outcomes of the previous stage with respect to both completeness of the footprint of deductive scenarios, and the effect of potential single points of failure on the safety of the overall architecture. The analysis uses scenarios formed by describing failures of particular modules to correctly provide particular service characteristics. UStep 3-1 Selection of failures for inductive scenarios:u The first step of this phase of assessment is to select particular module services (and their characteristics) for further investigation. For all but the simplest of architectures it is unreasonable to attempt to investigate all characteristics of every service provided by every module. Thus only a subset of potential failures should be considered. At minimum this should include: All service characteristics of interface modules. This will provide some assurance that the set of scenarios considered in phase 2 was complete. In our case study, the interface modules are: Interlock Handler, Separation Autopilot, Write Messages, INS, Initial and Target. All characteristics marked more than once by the same deductive scenario identifier during phase 2 (e.g. Occurrence and Timing characteristics of Mode_Control.Release), as these potentially indicate common modes of failure. All characteristics of any services marked by more than one second phase scenario identifier (e.g. Mode_Control.Mode and Transfer_Alignment.Report). These services (and the modules which provide them) may have much higher criticality than that identified by considering any individual scenario in phase 2. Also, service characteristics not marked at all during phase 2 may be of particular interest especially if the whole module does not bear any scenario s footprints. This may indicate that analysis team did not understand the services provided by the module and thus missed its potential contribution to hazards. UStep 3-2 Execution of inductive scenarios:u This is quite straightforward step, which is essentially the reverse of Step 2-2 above. In our case study, this step identified a number of important properties of the design which were not apparent from earlier activities. For example, when we considered the Separation_Autopilot.On service, we identified a hazard which we had previously missed; an attempt to actively control the missile fins while the missile is still attached to the launch vehicle may have a detrimental effect upon the pilot s control over the aircraft.

9 We also established that a Value characteristic of the Transfer Alignment module s Report service is critical with respect to avoiding firing a faulty (potentially uncontrollable) missile. Similarly, some IMU and Inertial Navigation failures occurring while the missile is in Launch mode (i.e. after the motor has been ignited but before the missile flies clear of the launch aircraft) may be catastrophic, as there are no possible mitigation mechanisms. Interestingly, we also discovered that due to the mitigation Firing Interlock provides, ensuring Mode Control has adequate Release service characteristics is more critical than ensuring it has adequate Mode service characteristics. Finally, a number of design requirements and assumptions (not explicit in the software architecture description) were uncovered; these included: The default state of Firing Interlock must be Prevent Ignition ; Interlock Handler must only flip the interlock on detection of Launch mode. If missile launch is abandoned (due to a detected internal failure or otherwise), the Electronic Unit must be reset in order to erase old missile status values (stored in the pool). Missile state data sent by the Inertial Navigation module (Calculate service) to the Transfer Alignment module must be time-stamped so that it can be detected; otherwise, continuous failure of Inertial Navigation to provide Calculate service (e.g. continuous omission failure) will lead to simultaneous failure of Transfer_Alignment.Report and Separation_Autopilot.Demand services, causing both hazards H1 and H6. UConclusions Current guidelines on conducting Preliminary System Safety Assessment are not suitable for early and immature architecture proposals. This is due to the emphasis on Fault Tree and other labour intensive methodologies. This paper has presented some early work on defining Lightweight PSSA a method for assessing software architectures which is more appropriate (and cost effective) in the context of immature designs. The method provides analysts with greater understanding of the safety implications of an architecture; it also ensures that the architecture description is complete and comprehensible enough in order to assess such implications. It facilitates a more rigorous PSSA process by establishing base events for inclusion in future fault trees and other analyses. Lightweight PSSA draws from established methods and concepts that have emerged from the fields of software architecture and software safety, but uses them in novel ways. It consists of three phases; the first phase of assessment is concerned with modelling dependencies between major architecture components, while the actual analysis is performed in the remaining two phases. The precise conduct of the analysis phases of the assessment is not rigidly defined. We believe that at this level of design maturity, an analysis providing a structure for facilitated brainstorming is most appropriate; in this respect our approach is similar to other software architecture analysis methods such as SAAM and ATAM. Our findings from trial applications of Lightweight PSSA are encouraging. The assessment process highlighted areas where software architecture was lacking in detail and clarity, and helped to identify assumptions about further design that were not otherwise clear. It allowed us to gain insight into how failures can result in hazards (including identifying hazards not captured by earlier analysis), what hazard mitigation mechanisms are already present in the architecture, and what can (and should) be incorporated at later design stages. Despite these positive findings, the method presented in this paper is merely a first step towards improving Preliminary System Safety Assessment. We are planning to conduct further research into the definition of Lightweight PSSA in order to: Extend the method beyond application software architectures. Define management aspects of the method (including constitution of suitable assessment teams, as well as integration of Lightweight PSSA into overall safety and development processes). Conduct further case studies on industrial examples. Finally, we are planning to integrate Lightweight PSSA with an improved method for conducting full-strength PSSA we are currently developing. This method is based on the Failure Propagation and Transformation Notation (FPTN) (ref. 12) and will address issues such as re-use of safety analysis artefacts as well as limiting the effects of design changes upon safety analysis. This will be the subject of a future paper.

10 References 1. Society of Automotive Engineers Inc, Aerospace Recommended Practice (ARP) 4754: Certification Considerations for Highly Integrated or Complex Systems, November Society of Automotive Engineers Inc, Aerospace Recommended Practice (ARP) 4761: Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment, December S. K. Dawkins, T.P. Kelly, J. A. McDermid, et al., Issues in the conduct of PSSA, In Proceedings of the 17th International System Safety Conference (ISSC), pp 77-86, 1999, System Safety Society. 4. P. Clements, F. Bschmann, L. Bass, et al. Documenting Software Architectures: Views and Beyond, Assison- Wesley, L. Bass, P. Clements and R. Kazman, Software Architectures in Practice, Addison-Wesley, R. Kazman, M. Klein and P. Clements, ATAM: Method for Architecture Evaluation, Technical Report, Software Engineering Institute Carnegie Mellon University, August D.J. Pumfrey, The Principled Design of Computer System Safety Analyses, D.Phil. thesis, The University of York, September M. Nicholson and J. McDermid, Extending PSSA for Complex Systems, in Proceedings of the 21st International System Safety Conference (ISSC), 2003, System Safety Society. 9. P. Lindsay and J. McDermid, Derivation of Safety Requirements for an Embedded Control System, Systems Engineering, Test and Evaluation Conference, Sydney, Australia, October S. E. Paynter, J. A. Armstrong and J. Haveman, ADL: An Activity Description Language for Real-Time Networks, Formal Aspects of Computing, 12(2): , H. R. Simpson, The Mascot Method, Software Engineering Journal, 1(3): , P. Fenelon, J. McDermid, M. Nicholson and D. Pumfrey, Towards Integrated Safety Analysis and Design, ACM Computing Reviews, 2(1): 21-32, 1994 Biographies O. Lisagor, Research Student, HISE Group, Computer Science Department, The University of York, Heslington, York, YO10 5DD, UK, telephone , fax , Oleg Lisagor is a research student at the University of York, working within the High Integrity Systems Engineering (HISE) group. He received a Masters of Engineering degree in Computer Systems and Software Engineering from York in His research interests lie in the general area of analysis of safety-critical systems at early stages of the system s life cycle and, in particular, he is concerned with safety-related analyses of software architectures. J. A. McDermid, Ph.D., Professor of Software Engineering, Computer Science Department, The University of York, Heslington, York, YO10 5DD, UK, telephone , 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. D. J. Pumfrey, D.Phil., Teaching and Research Fellow, HISE Group, Computer Science Department, The University of York, Heslington, York, YO10 5DD, UK, telephone , fax , david.pumfrey@cs.york.ac.uk. Dr. David Pumfrey is a teaching and research fellow in the High Integrity Systems Engineering group in York. His current research interests include improved methods of predictive safety analysis to help guide the early stages of design of critical systems, and new techniques for investigating the safety implications of hardware/software interactions in complex computer systems. He teaches on MSc and Certificate programmes in System Safety Engineering, and is one of the presenters of a highly successful series of short courses on system safety and safety cases.