Beavers safety, RAM, performance, and safety case capability

>>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 ;

Safety Case Management and Co-ordination.
Safety Plan development and execution including process definitions, competency criteria, process and competency audits
HAZOP's and FMEA's, and where needed, developing functional or design models, based on existing project documentation, to act as the "design intent" for any study.
Fault and event tree modeling. Our consultants have experience in the use of Isographs FT+ and RMC's Logan and other industry standard packages.
Conseqence modeling to estimate human, business and environment losses for accident sequences, for use on event tree branch consequences to determine risk, summing of risk to calculate measures such as fatalities per year, FN-curves (societal risk), and iso-risk contours (for planning studies), develping tolerability criteria, identifying risk reduction options, determining change in risk for each option, costing options and calculation of ALARP statements.
Determining SILS for functions and target apportionment between subsystems / products.
Performing Hierarchical Task Analysis (HTA's), human error studies, and calculating human error probabilities using methods such as HEART.
System availability and reliability studies using Reliability Block Diagrams, fault trees, and Markovian models, to determine system performance parameters, analyse parts holding and crewing level sensititiy to system performance characteristics. Our experience includes determining system performance, business loss, repair and SLA costs, and other entities allowing us to calculate though life costs. Our consultants are experienced in using tools such as Simul8 and AvSim.
Benchmarking existing performance levels, documenting known problems, establishing future system performance levels needed, perfomring gap analyses, and undertaking technology readiness reviews as part of gap closure feasability studies.
Gathering and sharing data between safety, RAM, human factors and ILS groups, and providing appropriate and co-ordinated inputs to requirements and design documents while ensure sech inputs meet good requirements engineering practices and have accompanying V & V (verification and validation) plans.

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;

Ensuring consistency between the requirements (capability and performance), the hazard log, via systems models.
Bring together and maintain key data to produce safety cases, particularly modular multi-level safety cases. Our approach includes documenting the safety (or RAM / Performance) requirement, its derivation e.g. tracing to the function that requires the safety requirement to mitigate a deviation or control a system property, the claim made that the requirement has been met, and the underlying evidence.
Using the functional or product performance data held in the log or requirements or specification documents to be exported for use in fault tree, event and RBD simulations. This can be increased to create sets of data for alternatives, which are then evaluated based on emergent properties at the parent level.
Reviewers have easy access to follow up evidence, derivations,and underlying assumptions.
Ensure changes to the requirements or design are traced through to the safety, RAM and performance analyses, firstly to assist in estimating the impact of making the proposed changed, then ensuring once approved all related data is updated, while maintaining a full, auditable, change history.

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.

Conceptual DOORS information model used to a hazard log and produce safety cases and shows the derivation of safety or other requirements based on the primary requirement

Conceptual DOORS information model used to a hazard log and produce safety cases and shows the derivation of safety or other requirements based on the primary requirement

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.

DOORS summary view for a simple hazard log module

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.

detail from the information model showing modules for holding third party data in DOORS as a surrogate module

detail from the information model showing modules for holding third party data in DOORS as a surrogate module

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.