|
|
|
|
An Introduction to Tools and Techniques
|
 |
This table summarises some of the Safety Assessment Tools and Techniques available to the safety assessor. Each of these tools has its own advantages and disadvantages and the extent to which these can be used during various phases of the product lifecycle, and the degree to which they can be applied to safety assessments, vary. For a list of Advantages and Limitations of each, see Appendix A to Aircraft System Safety: Military and Civil Aeronautical Applications.
It is extremely important to note that as the complexity of the tool increases so does the degree of training required for the user and/or the need for an experienced evaluation team to conduct the evaluation. On the plus side, the data derived from the more complex methodologies may be more supportable. Unfortunately, the primary disadvantage of such tools is that "trained subject matter experts" may have limited experience in the actual operational environment and, therefore, their evaluations may not be entirely applicable to the certification process.
To hide this text and give you more room to view the table of tools and techniques, click the "minus" sign symbol at the top right of the container surrounding this introduction.
|
|
 |
|
|
Tools and Techniques
|
|
| | Name | Description |
|
| SHEL Model | Propsed by Edwards(1998), it takes its name from the four main components: Software, Hardware, Environmental and Liveware The model is an illustration of the interrelationships between the three types of system resource and their environment - S = Software (i.e. rules, regulations, SOPs, customs, habits, etc
- H = Harware (i.e. physical assets)
- E = Environment (i.e. physical, political, social, economic)
- L= Liveware ( i.e. people) - L-H interface: The interaction between man and the machine (i.e. ergonomics) is probably the cause of most catastrophic accidents.
- L-S interface: Considers the interaction of human characteristics with the requirements of the rules, procedures etc.
- L-E interface: Considers how the human can cope in extreme conditions.
Model can be extended to be 3D: - H-H interface (e.g. plug an play devices)
- S-S interface (e.g. consistency of company operating procedures)
- L-L interface (e.g. command and control)
 |
|
| Single Function Diagram (SFD) | Shows schematically how a specific function is normally produced. |
|
| Single-Point Failure Analysis | This technique is to identify those failures, that would produce a catastrophic event in items of injury or monetary loss if they were to occur by themselves This approach is applicable to hardware systems, software systems, and formalized human operator systems [Tarrents, 1980] |
|
| Sneak Analysis (or Sneak Circuit Analysis) | Looks for unintended paths (flows) within an electrical system.
A Sneak Circuit is an unexpected path or logic flow within a system which, under certain conditions, can initiate an undesired function or inhibit a desired function. The path may consist of hardware, software, operator actions, or combinations of these elements. Sneak circuits are not the result of hardware failure but are latent conditions, inadvertently designed into the system, coded into the software program, or triggered by human error.
The traditional approach to sneak circuit analysis is manually dissect the schematic drawings and transforming them into structures called network trees. Sneak clues are then applied to these trees.
SNA can be performed using the Sneak Circuit Analysis Tool (SCAT), a PC based software package, and CapFast, an electrical circuit design and schematic editing tool. SCAT integrates with the schematic design package, CapFast.
Original version was Sneak Circuit Analysis, devised after Mercury Redstone rocket launch accident (1961)
See Def Stan 00-41 and Mil-Std-1543. |
|
| Software Failure Modes and Effects Analysis | This technique identifies software related design deficiencies through analysis of process flow-charting. It also identifies areas for verification/validation and test evaluation. [Tarrents, 1980] |
|
| Software Fault Tree Analysis | This technique is employed to identify the root cause(s) of a "top" undesired event. To assure adequate protection of safety critical functions by inhibits interlocks, and/or hardware [Tarrents, 1980] |
|
| Software Hazard Analysis | The purpose of this technique is to identify, evaluate, and eliminate or mitigate software hazards by means of a structured analytical approach that is integrated into the software development process. |
|
| Software Hazard Analysis and Resolution in Design (SHARD) | Very HAZOP like, but with different keywords (i.e. Early, Late, Omission, Commission and Value). Developed by the University of York. |
|
| Software Sneak Circuit Analysis | Software Sneak Circuit Analysis (SSCA) is designed to discover program logic that could cause undesired program outputs or inhibits, or incorrect sequencing/timing [Tarrents, 1980] |
|
| Standard Ergonomics Assessment Methodology (SEAM) | One of the largest human factors teams in the UK, part of Qinetiq's Centre for Human Sciences, has been presented with the Ergonomics Society's 2004 award for Human Factors Integration, sponsored by Thales. In making the award, the Society recognised the importance of the team's development of a software tool (SEAM), which they used to make ergonomic assessments on the Bowman tactical communications system - one of the largest change programmes ever undertaken by the British Army, which will transform the Army's land vehicle and infantry communications. The Qinetiq team was tasked by the Defence Procurement Agency to assess Bowman at five key design stages. SEAM (Standard Ergonomics Assessment Methodology) helped them to make rigorous and consistent ergonomic assessments of the system. The software tool was designed for use by all members of the team irrespective of experience. It assisted them with data collection, data storage and report writing and will now be used for other military and civilian projects.
See QinetiQ. |
|
|
|
|
|