Tag: risk-tracking-and-reporting

Categories
Blog Safety Management Tools & Techniques

Full Function Hazard Logs: A Deep Dive into Relational Databases

Computer Tracking Results
Photo by Lorenzo from Pexels

In this post ‘Full Function Hazard Logs: A Deep Dive into Relational Databases’, I explore some things we can do with a hazard log built upon a database.

In my 25-year career in safety engineering, I’ve seen many hazard logs and hazard tracking systems. Most of them were hosted in Microsoft Excel, but there were also commercial tools and bespoke databases. Let’s explore well beyond mere spreadsheets…

The Accident Sequence Illustrated.

In the realm of hazard management, navigating through the complexities of hazard logs, hazard tracking systems, and risk registers is crucial for ensuring safety and compliance. To shed light on this intricate process, we embark on a journey to explore the nuances of full-function hazard logs and their utilization within relational databases. Join us as we unravel the intricacies of hazard identification, risk assessment, and control measures within the realm of safety engineering.

Unveiling the Essence of Full Function Hazard Logs

Entities and Links in an Example Full-function Hazard Log

In our quest to decipher the essence of full-function hazard logs, we delve into the core components of relational databases. Our mission is clear: to unravel the labyrinth of entities within a hazard log, understand their interconnections, and discern the rationale behind data recording. By comprehending the diverse facets of hazard logs, we equip ourselves with the knowledge to tailor hazard log features to meet specific needs, ensuring efficiency and efficacy in hazard management processes.

Illustrating with Cassandra: A Glimpse into Hazard Log Tools

As we embark on this journey, we look closely at Cassandra, an exemplar of hazard log tools. While our focus remains steadfast on elucidating hazard management principles, Cassandra serves as a tangible illustration, offering a practical lens through which to explore complex concepts.

The Cassandra Hazard Log Logo
The Cassandra Hazard Log Logo

Through this illustrative example, we navigate the intricacies of accident causal control, dissecting the underlying hazard model that underpins our hazard management endeavors.

Deciphering Hazard Log Screens: A Comprehensive Overview

Venturing further into the realm of hazard log management, we dissect the various screens encapsulated within the hazard log interface.

A Screen with Accident-related Data and Links.

From the overview screen, where we gain a holistic view of accidents, hazards, causes, and controls, to the core screen, where we delve into the specifics of causal analysis, each screen offers a unique perspective on hazard management. By scrutinizing leading particulars, probability, severity, and post-control statuses, we unravel the intricacies of hazard identification and risk mitigation.

Unveiling the Power of Relational Databases

Central to our exploration is the underlying power of relational databases, where entities are intricately linked through many-to-many relationships. As we navigate through the database landscape, we witness the seamless integration of accidents, hazards, causes, and controls, each playing a pivotal role in shaping hazard management strategies. By harnessing the full potential of relational databases, we unlock a myriad of benefits, empowering us to make informed decisions and uphold safety standards with unwavering diligence.

Accessing Additional Resources: Empowering Your Hazard Management Journey

As we conclude our exploration of full-function hazard logs within relational databases, we extend an invitation to delve deeper into the realm of hazard management.

Through free email subscriptions and access to courses on safety engineering, we provide a gateway to further enrich your hazard management knowledge. Join our community of safety enthusiasts, engage in insightful discussions, and embark on a transformative journey toward bolstering safety practices within your organization.

Learn safety engineering with me, an industry professional with 25 years of experience, I have:

•Worked on aircraft, ships, submarines, ATMS, trains, and software;

•Tiny programs to some of the biggest (Eurofighter, Future Submarine);

•In the UK and Australia, on US and European programs;

•Taught safety to hundreds of people in the classroom, and thousands online;

•Presented on safety topics at several international conferences.

Categories
Blog Safety Management

What Have Hazard Logs Ever Done for Us?

What have hazard logs ever done for us?
An Aqueduct. Photo by Gary Spears in pexels.com

“What Have Hazard Logs Ever Done for Us? Well, there’s the aqueduct…” Monty Python’s Flying Circus may not be an obvious connection to hazard management, but it works! Hazard Logs – or Hazard Tracking Systems (HTS), which is a better term – are underappreciated but vital tools.

In this webinar on hazard logs, one of the topics that I will be covering is what a ‘full-function’ HTS can do. By that, I mean a purpose-built database, rather than just a spreadsheet. So here is a taster of the benefits, derived from my 25+ years of experience on system safety programs, large and small.

Key Elements of a Hazard Log

An HTS pulls together key safety data about:

  • Accidents: ‘An unintended event, or sequence of events, that causes harm’;
  • Accident Sequences: ‘The progression of events that results in an accident’;
  • Causes: that may lead to a hazard;
  • Controls (or mitigations): ‘A measure that, when implemented, reduces risk.’; and, of course
  • Hazards: ‘A physical situation or state of a system, often following from some initiating event, that may lead to an accident’.
Accident Sequence
Accident Sequence

Understanding how causes lead to hazards, and hazards lead to consequences, which may include (harmful) accidents, is fundamental to understanding accident sequences. This in turn helps us to understand the mechanisms that lead to harm – and defeat them.

Managing Many-to-Many Connections

A Hazard Log doesn’t just store data elements, it links those data together meaningfully to make information. A relational database does this by allowing us to make many-to-many connections between different classes of data.

Humorous illustration of linkages between data types in a Hazard Log or HTS
Hazard Log Connections

This allows us to do a lot of useful things. We’ve already mentioned understanding the mechanisms behind accident sequences. This allows us to design or select effective controls to interrupt the accident sequences and prevent harm.

Discovering Pathways to Harm

Understanding these links also enables us to see connections, for example between causes and accidents, which we had not seen before. This is important, as many severe accidents arise from unanticipated pathways to harm, perhaps in very specific circumstances. (For example, not shutting the bow doors of a ferry properly led to the flooding and capsizing of the Herald of Free Enterprise, killing 193 people.)

Change Impact Analysis

Understanding these connections also allows us to perform safety change impact analysis (‘the analysis of changes within a deployed product or application and their potential consequences’). In many programs I worked on, in-use incidents revealed that:

  • Designs were not working as intended;
  • Hazard controls were not as effective as thought;
  • Work done was not as designed; or that
  • The actual use of a system was not as foreseen.

If we know the links to something that has changed – what it affects / what affects it – then we can begin to estimate the impact. From experience, this occupies a lot of our time in in-service safety management.

Recovery and Improvement

In the real world things rarely stand still. There are usually many different stimuli for change (we’ve already mentioned our incidents/accidents). Our enterprise might have to raise its game for several reasons:

  • The Regulator demanding change or improvement;
  • Customers asking for more performance or more assurance;
  • The public reaction to incidents elsewhere in the market;
  • New technology or new competitors in our industry; or
  • Our commitment to continuous improvement.

Pareto analysis tells us that a minority of causes tend to dominate the effect. Thus, a small number of causes or initiating events drive the occurrence of hazards. Similarly, a minority of hazards will dominate incident and/or accident statistics.

We may know this from experience or analysis of our specific system, or we may have only generic data. It doesn’t matter.

Using these insights, we can use the linkages in the HTS to target particular causes, events, conditions, scenarios, hazards, etc. We identify the set that (should) make the biggest impact, the biggest difference. We can then rank the contributors in order of importance and tackle them.

Again, long and sometimes bitter experience tells me that safety practitioners will spend a lot of time doing this. Reacting to stimuli is a big part of safety management.

The Tool Supports the Process

Of course, we should be using tools to support the process. (The process is designed to produce the results or outcomes that we need). One example of such is the Risk Assessment process from ISO 31000, below.

Shows the elements, progression and cycle of the Risk Assessment Process from ISO 31000
The Risk Assessment Process

We want our HTS to support this process, storing the data that we get from the risk identification, analysis, and evaluation activities. We also want our Hazard Log to provide information that enables communication and consultation as well as monitoring and review (perhaps using a risk matrix).

Other Functions

Hazard Logs and HTS also perform many other functions. These may appear mundane, but when they go wrong they suddenly become very exciting! What Have Hazard Logs Ever Done for Us? They help us avoid these unwanted excitements, by providing:

Questions? Comments? Send me your feedback in the comments, below.

My name’s Simon Di Nucci. I’m a practicing system safety engineer, and I have been, for the last 25 years; I’ve worked in all kinds of domains, aircraft, ships, submarines, sensors, and command and control systems, and some work on rail air traffic management systems, and lots of software safety. So, I’ve done a lot of different things!

Categories
Blog Safety Management

Optimizing Safety: Active Hazard Management with Hazard Logs

Computer Tracking Results
Photo by Lorenzo from Pexels

In ‘Optimizing Safety: Active Hazard Management with Hazard Logs’ we look at how to unleash the power of this underrated tool!

Introduction

A Hazard Log is more than just a record; it’s a dynamic tool for actively managing safety risks associated with systems. This continually updated log encapsulates Hazards, Accident Sequences, and Accidents, ensuring a structured approach to risk management. Dive into the world of Hazard Logs to discover their application, advantages, and best practices for effective use.

Active Management with Hazard Logs

Overview

A Hazard Log serves as an ongoing record, meticulously updated to capture Hazards, Accident Sequences, and Accidents linked to a system. It acts as a comprehensive repository, providing insights into risk management decisions for each Hazard and Accident.

The Hazard Log is a structured method of keeping and referring to Safety Risk Evaluations and other information pertaining to a piece of equipment or system. It is the primary means of monitoring the status of all identified hazards, choices made, and risk-reduction actions done, and should be utilised to assist supervision by the Project Safety Committee and other stakeholders.

Hazards, Accident Sequences, and Accidents noted are those that could potentially occur as well as those that have already occurred. The title Hazard Log may be deceptive because the information saved relates to the overall Safety Programme and includes Accidents, Controls, Risk Evaluation, ALARP/SFARP rationale, and Hazard data.

Utilization and Administration

Administered by a dedicated Hazard Log Administrator, primary access is granted to add, edit, or close data records. All other personnel have read-only access, ensuring visibility of Hazards while maintaining control. Records are tracked using a status field, indicating stages such as opening, awaiting mitigation confirmation, or ALARP/SFARP justification.

Recording Hazards

Considered best practice, each Hazard is recorded as “open,” with ALARP/SFARP arguments treated provisionally until mitigation actions are confirmed. Hazards are not deleted but closed with appropriate justifications, reflecting changes in relevance.

As an example, suppose the mitigation is contingent on the development of an operational procedure. This may not be developed until far after the Hazard has been discovered in the early stages of design or construction.

Hazards should not be erased from the Hazard Log, but rather closed and labeled “out of scope” or “not considered credible” with adequate justification. If such Hazards are no longer thought to be relevant to the system, the Log entry should be modified to reflect this.

Application in Systems

The Hazard Log should focus on a specified system, detailing its scope and safety requirements. It records the evaluation of Hazards, residual risk assessments, and recommendations for mitigation or formal acceptance with ALARP/SFARP justification.

Because a Hazard Log is an organised method of collecting and referencing data and records on Hazards, as well as documenting the Risk Evaluation and other information relevant to an equipment or system, unambiguous cross-referencing to supporting documentation is critical. The supporting documentation can be directly incorporated in the Hazard Log or cross-referenced.

Establishing a Hazard Log: Why and When

Traceability

A Hazard Log is crucial for projects, offering traceability in the decision-making process, and justifying the assessed Safety Risk. Initiated at the program’s earliest stage, it remains a live document throughout the system life cycle.

As modifications are implemented in the system, the Hazard Log should be updated to reflect the current design standard by including new or changed Hazards and the associated residual risks. The Hazard Log must be checked frequently to verify that hazards are being managed effectively and that compelling safety arguments in the Safety Case can be created.

Advantages & Disadvantages

Advantages

The Hazard Log is a traceable record of the Project’s Hazard Management process and thus:

  • Ensures that the Project Safety Programme uses a consistent set of Safety information;
  • Facilitates oversight by the Safety Panel and other stakeholders of the current status of the Safety activities; and
  • Supports the effective management of possible Hazards and Accidents so that the associated Risks are brought up to and maintained at a tolerable level;

Disadvantages

  • The Hazard Log could include information about the relationship between hazards, accidents, and their control through the establishment and fulfilment of Safety Requirements. However, if it is not robust or well-structured, this may obscure the identification and clearance of Hazards.
  • If Hazards are not well defined when they are entered into the Hazard Log, the rigour enforced by the need for a clear audit trail of changes made may make it very difficult to maintain the Hazard and Accident records most effectively. Before beginning data entry, an appropriate structure should be created and agreed upon.

Choosing the Right Format: Electronic vs. Paper-Based

Electronic Format

While a Hazard Log can be produced in any format, an electronic format, often in databases like Microsoft Access or SQL Server, ensures quick cross-referencing and traceability. Proprietary tools like Cassandra or spreadsheet packages like Microsoft Excel offer flexibility.

Bespoke vs. Proprietary

Choosing between a bespoke database and a proprietary tool involves considerations of customizability and standardization. A bespoke system may be simple to administer, while a proprietary tool ensures consistency across programs.

In conclusion, Hazard Logs, when actively managed, emerge as indispensable tools for maintaining safety standards and facilitating informed decision-making. Understanding their application and choosing the right format ensures efficient risk management throughout a system’s life cycle.

We will explore more active hazard management in our upcoming blog post using Cassandra as a case study.

That was ‘Optimizing Safety: Active Hazard Management with Hazard Logs’. See another article of my articles on hazard logs here. I hope that you find them useful: leave a comment, below!

My name’s Simon Di Nucci. I’m a practicing system safety engineer, and I have been, for the last 25 years; I’ve worked in all kinds of domains, aircraft, ships, submarines, sensors, and command and control systems, and some work on rail air traffic management systems, and lots of software safety. So, I’ve done a lot of different things!

Categories
Blog Safety Management

Hazard Logs – a Brief Summary

Challenges of Online Learning
Photo by Lukas on Pexels.com

In Hazard Logs – a Brief Summary, we will give you an overview of this important safety management tool. This post serves as an introduction to longer posts and videos (e.g. Hazard Logs & Hazard Tracking Systems), which will provide you with much more content.

Hazard Logs – a Brief Summary

Description of Hazard Log

A Hazard Log is a continually updated record of the Hazards, Accident Sequences, and Accidents associated with a system. It includes information documenting risk management for each Hazard and Accident.

The Hazard Log is a structured means of storing and referencing Safety Risk Evaluations and other information relating to a piece of equipment or system. It is the principal means of tracking the status of all identified Hazards, decisions made and actions undertaken to reduce risks. It should be used to facilitate oversight by the Project Safety Committee and other stakeholders.

The Hazards, Accident Sequences, and Accidents recorded are those which could conceivably occur, as well as those which have already been experienced. The term Hazard Log may be seen as misleading since the information stored relates to the entire Safety Programme and covers Accidents, Controls, Risk Evaluation, and ALARP/SFARP justification, as well as data on Hazards.

Operation

The Hazard Log is maintained by a Hazard Log Administrator, who is responsible to the Project Safety Engineer/Manager. The Hazard Log Administrator has primary access to the Hazard Log allowing him/her to add, edit or close data records. All other personnel requiring access to the Hazard Log are normally allowed read-only access. This allows for visibility of Hazards to all but limits the control/administration of data records to the Hazard Log Administrator.

Records can be tracked by the use of a status field. This, for example, identifies whether the record has just been opened, is awaiting confirmation of mitigation actions, or is ALARP/SFARP.

It is best practice for the Hazard Log to record each Hazard as “open” and for ALARP/SFARP arguments to be provisional until all mitigation actions are confirmed to be satisfactorily completed. An example is where the mitigation depends upon the production of an operational procedure that may not be written until well after the Hazard is first identified in the early stages of design or construction.

Hazards should not be deleted from the Hazard Log, but closed and marked as “out of scope” or “not considered credible”, together with appropriate justification. Where such Hazards are no longer considered relevant to the system, the Log entry should be updated to reflect this.

Application

In general, the Hazard Log should relate to a specified system and record its scope of use, together with the safety requirements. When Hazards are identified, the Hazard Log should show how these Hazards were evaluated and note the resulting residual risk assessment; the Hazard Log should then record any recommendations for further action to mitigate the Hazards, or formally document acceptance of the Hazards and any ALARP/SFARP justification.

Since a Hazard Log is a structured way of storing and referencing data and records on Hazards, documenting the Risk Evaluation and other information relating to a piece of equipment or system, clear cross-referencing to supporting documentation is essential. The supporting documentation can be either directly embedded or cross-referenced within the Hazard Log.

When it Might be Used

A Hazard Log should be established for all projects. This will allow full traceability of the formal decision process which would justify the assessed level of Safety Risk.

The Hazard Log is established at the earliest stage of the program and should be maintained throughout the system life cycle as a “live” document or database. As changes are integrated into the system, the Hazard Log should be updated to incorporate added or modified Hazards and the associated residual risks noted to reflect the current design standard.

It is essential that the Hazard Log is reviewed at regular intervals, to ensure that Hazards are being managed appropriately and enable robust safety arguments in the Safety Case to be established.

Advantages, Disadvantages, and Limitations

Advantages 

The Hazard Log contains the traceable record of the Hazard Management process for the Project and therefore:

  • Ensures that the Project Safety Programme uses a consistent set of Safety information;
  • Facilitates oversight by the Safety Panel and other stakeholders of the current status of the Safety activities;
  • Supports the effective management of possible Hazards and Accidents so that the associated Risks are brought up to and maintained at a tolerable level;
  • Provides traceability of Safety decisions made.

Disadvantages 

  • The relationship between Hazards, Accidents, and their management through setting and meeting Safety Requirements could be included within the Hazard Log. However, if it is not sufficiently robust or well-structured, this may obscure the identification and clearance of Hazards;
  • If Hazards are not well defined when they are entered into the Hazard Log, then the rigor enforced by the need for a clear audit trail of changes made may make it very difficult to maintain the Hazard and Accident records in the most effective way. An appropriate structure should therefore be designed and agreed upon before data entry starts.

Comments

A Hazard Log can be produced in any format, but an electronic format is the most common, as this tends to provide the quickest means of cross-referring and providing traceability through the Hazard Log. A paper-based Hazard Log would have limitations for most defense Systems as it would become large, staff-intensive, and cumbersome as the System developed. This in turn introduces a significant maintenance overhead for a project.

The electronic form of the Hazard Log can be developed using Database development tools like Microsoft Access or SQL Server. Alternatively, you can use an existing application such as DOORS. Alternatively, it can be completed in a simple spreadsheet package such as Microsoft Excel. The UK Ministry of Defence’s preferred Hazard Log tool was Cassandra, a proprietary Database based upon Microsoft Access.  (We will use Cassandra as an example in another blog post.)

A bespoke Database enables the originator to custom define fields appropriate to the System. Conversely, a proprietary tool allows for a consistent and standardized approach across a range of programs. A bespoke system may be relatively simple to administer and manipulate, whereas a proprietary tool may require external training. Widespread use of different bespoke solutions may become unmanageable.

Sources of Additional Information

Additional guidance on the Hazard Log can be found within the following references: MoD’s Project-Oriented Safety Management System – procedure SMP11 – Hazard Log.  An example Hazard Log structure is also presented there.

Copyright Acknowledgement

In this article, I have used material from a UK Ministry of Defence guide. It is reproduced under the terms of the UK’s Open Government Licence.

Hazard Logs – a Brief Summary: Ask Me Anything!