Copyright Beaver 2000/2003
>>Home >> Safety, Reliability and Performance Analysis
|Our consultants have over 10 years experience in system safety engineering, RAM, and performance studies working to DEF STAN 00-55, DEF STAN 00-56, and MIL STD 882C/D including the application of the following techniques, particularly at the system level ;|
Beaver bring added value to projects by applying our experience in safety, RAM, human factors and ILS studies with our requirements management capability. A particular area of expertise is in ensuring consistency between the requirements, safety and RAM analyses, the resulting safety and RAM requirements, and the design, together with the verification and validation evidence. This is an area we have focused on for over 10 years and is now being given prominance in safety case studies, for example in Deriving Safety Requirements using Scenarios by Dr Tim Kelly of the University of York. Beavers understanding of the methods, work flows and concurrency between them on real projects allows us for example to maintain hazard logs and develop safety cases which address the following issues and offers the following advantages;
An example of a conceptual information model which implements the above is shown below. From the user or system primary requirements, traces are established to a behavioural model, which is then analysed, for example using a HAZOP or FMEA approach. This identifies deviations, which are then ranked for severity, likelihood and risk, and control measures established, and its these control that become the derived requirements, whether technical or management process, and are flowed back into the originating requirement document.
The approach uses a module to hold hazard and causal data. For example high level deductive analysis of the system, such as using preliminary scoping statements from the user requirements document allows top level hazards to be identified, often using a check list. A more rigorous method, in subsequent iterations, uses inductive methods such as a Hazop, to analyse deviations to the functionality, determine the local and system effects, which can be categorised as contributors to one or more hazards. Latter the causes can be structured into fault trees for each hazard, incorporating the preventative measures and failure parameters, to determine hazard frequencies. Similar approaches can be used for determining causes to protection system failures for event tree nodes.
The information model ensures the safety requirements, which are generally derived, are fully traced to the behavoural model based on the primary requirements from the requirements document. The analysis of the behavoural model, using the Hazop or FMEA, can also incorporated in to the information model.
An example of a view from DOORS hazard log such the assignment of severity and likelihoods pre and post control, and automatic calculation of the risk level and tolerable based on a project customised risk matric is shown above. Additional DOORS views provide process support for process activities such for tracking, task assignment and reviewing the relationship between oringiating requirements and derived (control measure) requirements. The view shows both the links from the originating function, a summary of the threat (derived using a HAZOP, FMEA, or check list), and the resulting derived requirements traced back to the URD for example.
The process loop of analysing the primary requirements continues until the requirements - behavoural model is stable and no more deviations can be found. For apportionment of numeric targets to multiple allocated requirements or allocated across subsystems, such behavioural models can be simulated. For example, consider a parent requirement for a function to perform a specific task, in a given time, with a certain level of reliability. This would typically give rise to a number of lower level requirements addressing subfunctions with performance requirements such as MTTF, MTTR, timing charactersitics, SIL levels which place constraints on allowed solution architectures, and process requirements. The structuring of this information allows us to demonstrate requirements verification, showing the parent is achived by the lower level requirements, as well as acting as the basis for subsuquent product verification and validation planning, evidence collection and review. All this is needed to demonstrate the original function can be perfomed safely or reliably.
This approach brings together the requirements, safety / RAM / ILS and V&V teams, by using a single respository. Beavers experience in using this approach dates back over 10 years, has been continuously refined and customised for each specific clients needs, and is now implemented using DOORS as described in requirements management services section.
The following diagram shows how part of the conceptual information model is implemented into a DOORS project and integrated with third party tools. For tools, such as DOORS / CASEwise or DOORS / Systems Architect, bridges already exist, and the tools can be used for behavioural and performance analysis, for other tools or where existing tool bridges do not support your process Beaver can develop custom bridges to import / export between the tools, using DXL, VB and SQL scripts.
Organisations may already have hazard logs established using MS Access or SQL, or are using third party applications such as Cassandra , in these circumstances we develop a surrogate module in DOORS to hold a duplicate of key data from the existing tool, then users or Beavers analysts develop tracinging between the model, log and requirements document, at business / mission, user, system, subsystem or product level. This is our added value - joining together these data sets, ensuring consistency between data, providing the capability to review the quality of the arguments to meeting the requirement, and reducing the effort and time to produce documents such verification cross reference indexes (VCRI), safety reports, safety cases, and reliability cases.