System Safety Pro

Monday, November 11, 2024

How to Understand Safety Standards

Learn How to Understand Safety Standards with this FREE session from The Safety Artisan.

In this module, Understanding Your Standard, we’re going to ask the question: Am I Doing the Right Thing, and am I Doing it Right? Standards are commonly used for many reasons. We need to understand our chosen system safety engineering standard, in order to know: the concepts, upon which it is based; what it was designed to do, why and for whom; which kinds of risk it addresses; what kinds of evidence it produces; and it’s advantages and disadvantages.

Understand Safety Standards : You'll Learn to

- List the hazard analysis tasks that make up a program; and

- Describe the key attributes of Mil-Std-882E.

https://youtu.be/JTcBax2nNvE

Understanding Your Standard

Topics: Understand Safety Standards

Aim: Am I Doing the Right Thing, and am I Doing it Right?

- Standards: What and Why?

- System Safety Engineering pedigree;

- Advantages – systematic, comprehensive, etc:

- Disadvantages – cost/schedule, complexity & quantity not quality.

Transcript: Understand Safety Standards

Click here for the Transcript on Understanding Safety Standards

In Module Three, we're going to understand our Standard. The standard is the thing that we're going to use to achieve things - the tool. And that's important because tools designed to do certain things usually perform well. But they don’t always perform well on other things. So we're going to ask ‘Are we doing the right thing?’ And ‘Are we doing it right?’

What and Why?

So, what are we going to do, and why are we doing it? First of all, the use of standards in safety is very common for lots of reasons. It helps us to have confidence that what we're doing is good enough. We've met a standard of performance in the absolute sense. It helps us to say, ‘We've achieved standardization or commonality in what we're doing’. And we can also use it to help us achieve a compromise. That can be a compromise across different stakeholders or across different organizations. And standardization gives us some of the other benefits as well. If we're all doing the same thing rather than we're all doing different things, it makes it easier to train staff. This is one example of how a standard helps.

However, we need to understand this tool that we're going to use. What it does, what it's designed to do, and what it is not designed to do. That's important for any standard or any tool. In safety, it's particularly important because safety is in many respects intangible. This is because we're always looking to prevent a future problem from occurring. In the present, it's a little bit abstract. It's a bit intangible. So, we need to make sure that in concept what we're doing makes sense and is coherent. That it works together. If we look at those five bullet points there, we need to understand the concept of each standard. We need to understand the basis of each one.

And they’re not all based on the same concept. Thus some of them are contradictory or incompatible. We need to understand the design of the standard. What the standard does, what the aim of the standard is, why it came into existence. And who brought it into existence. To do what for who - who's the ultimate customer here?

And for risk analysis standards, we need to understand what kind of risks it addresses. Because the way you treat a financial risk might be very different from a safety risk. In the world of finance, you might have a portfolio of products, like loans. These products might have some risks associated with them. One or two loans might go bad and you might lose money on those. But as long as the whole portfolio is making money that might be acceptable to you. You might say, ‘I'm not worried about that 10% of my loans have gone south and all gone wrong. I'm still making plenty of profit out of the other 90%’. It doesn't work that way with safety. You can't say ‘It's OK that I've killed a few people over here because all this a lot over here are still alive!’. It doesn't work like that!

Also, what kind of evidence does the standard produce? Because in safety, we are very often working in a legal framework that requires us to do certain things. It requires us to achieve a certain level of safety and prove that we have done so. So, we need certain kinds of evidence. In different jurisdictions and different industries, some evidence is acceptable. Some are not. You need to know which is for your area.

And then finally, let's think about the pros and cons of the standard, what does it do well? And what does it do not so well?

System Safety Pedigree

We're going to look at a standard called Military Standard 882E. Many decades ago, this standard developed was created by the US government and military to help them bring into service complex-cutting edge military equipment. Equipment that was always on the cutting edge. That pushed the limits of what you could achieve in performance.

That’s a lot of complexity. Lots of critical weapon systems, and so forth. And they needed something that could cope with all that complexity. It's a system safety engineering standard. It's used by engineers, but also by many other specialists. As I said, it's got a background from military systems. These days you find these principles used pretty much everywhere. So, all the approaches to System Safety that 882 introduced are in other standards. They are also in other countries.

It addresses risks to people, equipment, and the environment, as we heard earlier. And because it's an American standard, it's about system safety. It's very much about identifying requirements. What do we need to happen to get safety? To do that, it produces lots of requirements. It performs analyses in all those requirements and generates further requirements. And it produces requirements for test evidence. We then need to fulfill these requirements. It's got several important advantages and disadvantages. We're going to discuss these in the next few slides.

Comprehensive Analysis

Before we get to that, we need to look at the key feature of this standard. The strengths and weaknesses of this standard come from its comprehensive analysis. And the chart (see the slide) is meant to show how we are looking at the system from lots of different perspectives. (It’s not meant to be some arcane religious symbol!) So, we're looking at a system from 10 different perspectives, in 10 different ways.

Going around clockwise, we've got these ten different hazard analysis tasks. First of all, we start off with preliminary hazard identification. Then preliminary hazard analysis. We do some system requirements hazard analysis. So, we identify the safety requirements that the system is going to meet so that we are safe. We look at subsystem and system hazard analysis. At operating and support hazard analysis - people working with the system. Number seven, we look at health hazard analysis - Can the system cause health problems for people? Functional hazard analysis, which is all about what it does. We're thinking of sort of source software and data-driven functionality. Maybe there's no physical system, but it does stuff. It delivers benefits or risks. System of systems hazard analysis – we could have lots of different and/or complex systems interacting. And then finally, the tenth one - environmental hazard analysis.

If we use all these perspectives to examine the system, we get a comprehensive analysis of the system. From this analysis, we should be confident that we have identified everything we need to. All the hazards and all the safety requirements that we need to identify. Then we can confidently deliver an appropriate safe system. We can do this even if the system is extremely complex. The standard is designed to deal with big, complex cutting-edge systems.

Advantages #1

In fact, as we move on to advantages, that's the number one advantage of this standard. If we use it and we use all 10 of those tasks, we can cope with the largest and the most demanding programs. I spent much of my career working on the Eurofighter Typhoon. It was a multi-billion-dollar program. It cost hundreds of billions of dollars, four different nations worked together on it. We used a derivative of Mil. Standard 882 to look at safety and analyze it. And it coped. It was powerful enough to deal with that gigantic program. I spent 13 years of my life on and off on that program so I'd like to think that I know my stuff when we're talking about this.

As we've already said, it's a systematic approach to safety. Systems, safety, engineering. And we can start very early. We can start with early requirements - discovery. We don't even need a design - we know that we have a need. So we can think about those needs and analyze them.

And it can cover us right through until final disposal. And it covers all kinds of elements that you might find in a system. Remember our definition of ‘system’? It’s something that consists of hardware, software, data, human beings, etc. The standard can cope with all the elements of a system. In fact, it’s designed into the standard. It was specifically designed to look at all those different elements. Then to get different insights from those elements. It’s designed to get that comprehensive coverage. It’s really good at what it does. And it involves, not just engineers, but people from all kinds of other disciplines. Including operators, maintainers, etc, etc.

I came from a maintenance background. I was either directly or indirectly supporting operators. I was responsible for trying to help them get the best out of their system. Again, that's a very familiar world to me. And rigorous standards like this can help us to think rigorously about what we're doing. And so get results even in the presence of great complexity, which is not always a given, I must say.

So, we can be confident by applying the standard. We know that we're going to get a comprehensive and thorough analysis. This assures us that what we're doing is good.

Advantages #2

So, there's another set of advantages. I've already mentioned that we get assurance. Assurance is ‘justified confidence’. So we can have high confidence that all reasonably foreseeable hazards will be identified and analyzed. And if you're in a legal jurisdiction where you are required to hit a target, this is going to help you hit that target.

The standard was also designed for use in contracts. It’s designed to be applied to big programs. We’d define that as where we are doing the development of complex high-performance systems. So, there are a lot of risks. It's designed to cope with those risks.

Finally, the standard also includes requirements for contracting, for interfaces with other systems, for interfaces with systems engineering. This is very important for a variety of disciplines. It’s important for other engineering and technical disciplines. It’s important for non-technical disciplines and for analysis and recordkeeping. Again, all these things are important, whether it is for legal reasons or not. We need to do recordkeeping. We need to liaise with other people and consult with them. There are legal requirements for that in many countries. This standard is going to help us do all those things.

But, of course, in a standard everything has pros and cons and Mil. Standard 882 is no exception. So, let's look at some of the disadvantages.

Disadvantages #1

First of all, a full system safety program might be overkill for the system that you want to use, or that you want to analyze. The Cold War, thank goodness, is over; generally speaking, we're not in the business of developing cutting-edge high-performance killing machines that cost billions and billions of dollars and are very, very risky. These days, we tend to reduce program risk and cost by using off-the-shelf stuff and modifying it. Whether that be for military systems, infrastructure in the chemical industry, transportation, whatever it might be. Very much these days we have a family of products and we reuse them in different ways. We mix and match to get the results that we want.

And of course, all this comprehensive analysis is not cheap and it's not quick. It may be that you've got a program that is schedule-constrained. Or you want to constrain the cost and you cannot afford the time and money to throw a full 882 program at it. So, that's a disadvantage.

The second family of problems is that these kinds of safety standards have often been applied prescriptively. The customer would often say, ‘Go away and go and do this. I'm going to tell you what to do based on what I think reduces my risk’. Or at least it covers their backside. So, contractors got used to being told to do certain things by purchasers and customers. The customers didn't understand the standards that they were applying and insisting upon. So, the customers did not understand how to tailor a safety standard to get the result that they wanted. So they asked for dumb things or things that didn't add value. And the contractors got used to working in that kind of environment. They got used to being told what to do and doing it because they wouldn't get paid if they didn't. So, you can't really blame them.

But that's not great, OK? That can result in poor behaviors. You can waste a lot of time and money doing stuff that doesn't actually add value. And everybody recognizes that it doesn't add value. So you end up bringing the whole safety program into disrepute and people treat it cynically. They treat it as a box-ticking exercise. They don't apply creativity and imagination to it. Much less determination and persistence. And that's what you need for a good effective system safety program. You need creativity. You need imagination. You need people to be persistent and dedicated to doing a good job. You need that rigor so that you can have the confidence that you're doing a good job because it's intangible.

Disadvantages #2

Let's move onto the second kind of family of disadvantages. And this is the one that I've seen the most, actually, in the real world. If you do all 10 tasks and even if you don't do all 10, you can create too many hazards. If you recall the graphic from earlier, we have 10 tasks. Each task looks at the system from a different angle. What you can get is lots and lots of duplication in hazard identification. You can have essentially the same hazards identified over and over again in each task. And there's a problem with that, in two ways.

First of all, quality suffers. We end up with a fragmented picture of hazards. We end up with lots and lots of hazards in the hazard log, but not only that. We get fragments of hazards rather than the real thing. Remember I said those tests for what a hazard really is? Very often you can get causes masquerading as hazards. Or other things that that exacerbating factors that make things worse. They're not a hazard in their own right, but they get recorded as hazards. And that problem results in people being unable to see the big picture of risk. So that undermines what we're trying to do. And as I say, we get lots of things misidentified and thrown into the pot. This also distracts people. You end up putting effort into managing things that don't make a difference to safety. They don't need to be managed. Those are the quality problems.

And then there are quantity problems. And from personal experience, having too many hazards is a problem in itself. I've worked on large programs where we were managing 250 hazards or thereabouts. That is challenging even with a sizable, dedicated team. That is a lot of work in trying to manage that number of hazards effectively. And there's always the danger that it will slide into becoming a box-ticking exercise. Superficial at best.

I've also seen projects that have two and a half thousand hazards or even 4000 hazards in the hazard log. Now, once you get up to that level, that is completely unmanageable. People who have thousands of hazards in a hazard log and they think they're managing safety are kidding themselves. They don't understand what safety is if they think that's going to work. So, you end up with all these items in your hazard log, which become a massive administrative burden. So people end up taking shortcuts and the real hazards are lost. The real issues that you want to focus on are lost in the sea of detail that nobody will ever understand. You won’t be able to control them.

Unfortunately, Mil. Standard 882 is good at generating these grotesque numbers of hazards. If you don't know how to use the standard and don't actively manage this issue, it gets to this stage. It can go and does go, badly wrong. This is particularly true on very big programs. And you really need clarity on big projects.

Summary of Module

Let's summarize what we've done with this module. The aim was to help us understand whether we're doing the right thing and whether we've done it right. And standards are terrific for helping us to do that. They help us to ensure we're doing the right thing. That we're looking at the right things. And they help us to ensure that we're doing it rigorously and repeatedly. All the good quality things that we want. And Mil. Standard 882E that we're looking at is a system safety engineering standard. So it's designed to deal with complexity and high-performance and high-risk. And it's got a great pedigree. It's been around for a long time.

Now that gives advantages. So, we have a system safety program with this standard that helps us to deal with complexity. That can cope with big programs, with lots of risks. That's great.

The disadvantages of this standard are that if we don't know how to tailor or manage it properly, it can cost a lot of money. It can take a lot of time to give results which can cause problems for the program. And ultimately, you can accidentally ignore safety if you don't deliver on time. And it can generate complexity. And it can generate a quantity of data that is so great that it actually undermines the quality of the data. It undermines what we're trying to achieve. In that, we get a fragmented picture in which we can't see the true risks. And so we can’t manage them effectively. If we get it wrong with this standard, we can get it really wrong. And that brings us to the end of this module.

This is Module 3 of SSRAP

This is Module 3 from the System Safety Risk Assessment Program (SSRAP) Course. Risk Analysis Programs – Design a System Safety Program for any system in any application. You can access the full course here.

You can find more introductory lessons at Start Here.

#coursesafetyengineering #engineersafety #ineedsafety #knowledgeofsafety #learnsafety #MilStd882E #needforsafety #riskassessment #safetyblog #safetydo #safetyengineer #safetyengineerskills #safetyengineertraining #safetyengineeringcourse #safetyprinciples #safetystandard #softwaresafety #systemsafety #theneedforsafety #understandsafetystandards #whatarethesafetystandards

Simon Di Nucci https://www.safetyartisan.com/2021/04/16/ssrap-3-understanding-your-standard/

Friday, November 8, 2024

Crafting a Safety Case and Safety Case Report
Crafting a Safety Case and Safety Case Report: A Comprehensive Guide for Project Safety Assurance - PART 1

Introduction

Building a robust Safety Case and Safety Case Report is essential to ensuring the safety and regulatory compliance of complex systems within the Ministry of Defence (MOD) and similarly regulated industries. From risk management and regulatory compliance to stakeholder approval, these documents play a pivotal role in documenting and demonstrating that a system meets safety requirements throughout its lifecycle.

DefinitionsTo understand the scope and purpose of these documents, we’ll start with definitions.

What is a Safety Case?Defined in Def Stan 00-056, a Safety Case is:

“A structured argument, supported by a body of evidence that provides a compelling, comprehensible, and valid case that a system is safe for a given application in a given environment.”

What is a Safety Case Report?Also defined in Def Stan 00-056, a Safety Case Report is:

“A report that summarises the arguments and evidence of the Safety Case, and documents progress against the Safety Programme.”

Objectives of the Safety Case

A well-prepared Safety Case achieves several key objectives:

- Documenting EvidenceA thorough record of all evidence ensures that the system meets established Safety Requirements and all identified risks are As Low As Reasonably Practicable (ALARP).

- Safe Execution of ActivitiesFor systems undergoing testing or trials, the Safety Case ensures these activities can proceed without jeopardizing safety.

- Justifying Safety of the SystemBy clearly articulating the arguments and evidence, the Safety Case justifies the system's safety through validated processes and assessments.

- Gaining ApprovalIn cases where safety approvals are required beyond the project level, the Safety Case serves as the official documentation submitted to regulators or higher authorities for review.

Procedure for Developing a Safety Case

The creation of a Safety Case within the MOD follows a well-structured, iterative approach, evolving alongside the project from concept through to service.

Step-by-Step Process

The Safety Case is generated in stages, starting with conceptual safety requirements and progressing through assessment, development, and manufacturing stages. The document consolidates safety data and insights from contractors, MOD procedures, and risk assessments, providing a holistic picture of safety efforts and compliance.

- Incorporating Contractor and MOD DataThe Safety Case combines all safety assessments and risk management activities, ensuring comprehensive and traceable safety information.

- Leveraging Diverse EvidenceSafety evidence can vary, including historical, analytical, test, and expert judgment inputs. A structured approach ensures that all critical safety information is preserved and accessible.

- Compliance and Regulatory ApprovalsThe Safety Case facilitates submissions to MOD safety authorities for approvals, such as safety certificates or internal safety audits.

Why the Safety Case Concept is Good Practice

Several key factors make the Safety Case framework essential in high-risk industries, including defense and manufacturing:

- Prioritization of Safety Efforts: Risk assessments at the core of the Safety Case help allocate resources effectively.

- Adherence to Legal Standards: The written evidence in a Safety Case aligns with common law requirements, ensuring robust legal compliance.

- Efficient Knowledge Transfer: Documented safety records reduce risks associated with high staff turnover.

- Cost-Efficiency and Safety Culture: Implementing a structured safety management system reduces accidents, boosts morale, and supports a proactive safety culture.

Producing the Safety Case Documentation

An effective Project Safety Management Plan is critical to the organization of the Safety Case documentation. It should include:

- Role AssignmentsDesignate a responsible individual to oversee the safety documentation process.

- Approval ProtocolsDefine both internal and external approval workflows to streamline safety documentation reviews.

- Documentation for All StagesEnsure that documentation covers the design, construction, manufacture, and operational phases, aligning with the safety significance of each stage.

Safety Case Documentation Lifecycle

The Safety Case is dynamic and should adapt throughout the project lifecycle to maintain relevance as the system evolves.

- System Development and TrialsThe Safety Case Report must evolve during development and trials, reflecting any updates to design or safety features.

- Project MilestonesAt each project milestone, the Safety Case Report should validate that safety standards are being met and provide support for decision-making regarding continued development.

- Variant SystemsSafety Cases can be structured to accommodate system variations by creating a single report with variant-specific appendices or compatibility matrices.

Handling Safety Case Caveats

Projects may occasionally need to progress with certain “caveats” or limitations due to incomplete safety information. When this occurs, the following should be considered:

- Clear Communication of CaveatsDefine the limitations and inform all relevant stakeholders, ensuring they understand any usage restrictions.

- Compliance MonitoringEnforce caveat compliance and evaluate whether limitations may introduce additional risks.

Long-Term Safety Documentation Retention

MOD mandates stringent retention periods for safety documentation based on potential risks and exposure, ranging from 2 to 50 years depending on the nature of the hazard. Retention policies are essential for maintaining comprehensive records for the MOD and assisting in post-project reviews or incident investigations.

Transparency in Safety Information Disclosure

While certain MOD establishments may restrict the disclosure of sensitive information under the Public Interests Disclosure Act, unclassified safety documentation should remain accessible to relevant parties and stakeholders, supporting transparency in public safety efforts.

By following the guidance outlined above, project teams can ensure that their Safety Cases not only meet MOD requirements but also foster a culture of safety excellence, accountability, and continuous improvement.

Crafting a Safety Case and Safety Case Report Part 2 is coming soon!

Meet the Author

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.
#ALARPSafetyStandards #DefStan00056SafetyCase #MODSafetyRegulations #ProjectSafetyMilestones #SafetyCaseReport #SafetyManagementSystem
Simon Di Nucci https://www.safetyartisan.com/?p=4139

Thursday, November 7, 2024

Monday, November 4, 2024

Why Call it The Safety 'Artisan'?

Why did I call my business The Safety 'Artisan'?

artisan/ˈɑːtɪzan,ɑːtɪˈzan/Learn to pronounce noun

A worker in a skilled trade, especially one that involves making things by hand. "street markets where local artisans display handwoven textiles, painted ceramics, and leather goods"

https://youtu.be/-qOAP0AxDHM

Why Call it The Safety 'Artisan'?

Why The Safety 'Artisan'?

Hi, everyone. When I was choosing a name for my business, I thought of quite a lot of alternatives, but I settled on The Safety Artisan for three reasons. First, I liked the meaning of the word, the idea of an individual person pursuing their craft and trying to do it to the very best of their abilities.

Second, I liked the application because I've worked on a lot of very large, even multi-billion-dollar projects; but we're still knowledge workers. We're still individuals who have to be competent at what we do in order to deliver a safe result for people.

And third, I liked the idea, the image of the cottage industry, the artisan working at home as I am now, and delivering goods and services that other people can use wherever they are. And indeed, you might be home or you might be on your mobile phone listening to this.

So I liked all three of those things. I thought, yes, that's what I'm about. That's what I believe in and want to do. And if that sounds good to you, too, then please check out The Safety Artisan, where I provide #safety #engineering #training.

Learn more about me here.

#coursesafetyengineering #engineersafety #ineedsafety #knowledgeofsafety #learnsafety #needforsafety #safetyartisan #safetyblog #safetydo #safetyengineer #safetyengineerskills #safetyengineertraining #safetyengineering #safetyengineeringcourse #safetyprinciples #safetytraining #softwaresafety #theneedforsafety

Simon Di Nucci https://www.safetyartisan.com/2021/03/26/why-call-it-the-safety-artisan/

Friday, November 1, 2024

In-Service Safety Management System
In-Service Safety Management System: Ensuring Long-Term Safety for Military Equipment

Safety is paramount when it comes to military operations, especially for in-service equipment relied upon by personnel daily. This article delves into the intricacies of maintaining an In-Service Safety Management System, offering insight into how safety practices are implemented, monitored, and evolved over time.

Introduction: Why In-Service Safety Matters

When military equipment enters service, the journey of ensuring its safe use doesn’t end there. An effective In-Service Safety Management System (SMS) oversees all safety-related aspects of equipment throughout its operational life. From day-to-day safety practices to long-term risk management, the SMS is vital for sustained safety performance. It also provides a roadmap for identifying, documenting, and addressing safety requirements as equipment evolves over time.

Key Definitions

A Safety Management System, according to Def Stan 00-056, is defined as:

“The organisational structure, processes, procedures, and methodologies that enable the direction and control of the activities necessary to meet safety requirements and safety policy objectives.”

This structure ensures every team member understands the standards and processes needed to maintain operational safety.

Objectives: What an In-Service SMS Aims to Achieve

The primary objectives of an in-service SMS are twofold:

- To recognize and uphold the safety requirements essential for equipment performance.

- To continuously document these processes, forming an auditable Safety Case to maintain accountability.

An effective SMS aligns with various support areas, referred to as "Lines of Development." These encompass personnel, training, sustainability, infrastructure, and facilities, ensuring that each line functions in sync for safe operations from the equipment's inception to its eventual decommissioning.

The SMS also involves continuous Risk Management, adjusting to changes such as equipment enhancements or new usage contexts. This proactive monitoring ensures that safety assurance is consistently updated and accurate.

Procedure for Sustaining Safety Performance

The SMS structure is implemented through the following methods:

- Safety ControlsEssential safety controls cover every phase, from operation to disposal, to reduce risks associated with the equipment. This includes operational limitations, maintenance, emergency preparedness, training, storage, transportation, and waste disposal.

- Safety Information ManagementManaging information effectively is vital. Safety data, incident reports, and safety improvement suggestions should be systematically documented, archived, and shared with relevant stakeholders. Maintaining a Hazard Log and a Safety Case as part of the Safety Management Plan ensures all safety data is up-to-date and readily accessible.

- Continuous Improvement and Safety ReviewsThrough regular audits, inspections, and incident reporting, the SMS can continually improve by identifying and addressing weaknesses. This proactive monitoring helps ensure that safety risks remain controlled over time.

- Configuration ManagementMaintaining a consistent standard for the equipment, including hardware, software, and documentation, is integral to the SMS. Regular reviews address potential issues like obsolescence or outdated manuals to ensure sustained safety performance.

- Risk ManagementAs modifications and enhancements are made, risk management processes like Hazard Analysis and Risk Evaluation ensure new risks are assessed, managed, and documented.

- Lines of DevelopmentThe SMS covers various developmental lines, from training and sustainability to equipment upgrades. Each line contributes to the system’s overall safety, focusing on creating an infrastructure that is both resilient and adaptable.

Safety Records and Documentation: A Foundation for Accountability

The in-service SMS relies on a foundation of well-maintained records. Documents such as the System Requirements Document, Through Life Management Plan, and Project Safety Management Plan with RACI (Responsible, Accountable, Consulted, Informed) charts support clear communication and accountability among stakeholders. Comprehensive documentation is essential for tracking compliance, reviewing safety measures, and justifying safety performance in the event of an audit.

Potential Risks and Warnings

It’s crucial to establish the SMS requirements early in the project lifecycle. Without these, the project may face delays or even safety risks during operation. Other potential risks include gaps in safety roles or inadequate documentation. An outdated or insufficiently maintained SMS may allow lapses in safety that could result in operational hazards or accidents.

Ongoing Review and Development

The SMS must remain dynamic to handle evolving requirements. Major changes, such as equipment modifications or regulatory updates, require a thorough review of the SMS. This adaptive approach helps ensure that safety protocols evolve alongside the equipment, preventing oversights or outdated practices.

Timing for Effective SMS Implementation

An SMS should ideally be drafted early and continually updated as the project progresses. By staying aligned with project developments, it ensures a seamless transition to the in-service phase. A Responsible, Accountable, Consulted, Informed (RACI) chart outlines the responsibilities of every stakeholder, creating a structured approach to safety management. Regular updates also ensure that each stage of the project reflects current safety standards.

Conclusion

For military equipment, safety isn’t a one-time effort but an ongoing commitment. An In-Service Safety Management System provides a comprehensive framework that maintains, monitors, and evolves safety practices, ensuring the safety of both the equipment and the personnel who rely on it.

Required Inputs

This procedure for the Safety Case and Safety Case Report requires inputs from:

- Outputs from Procedure SMP01 – Safety Initiation;

- Outputs from Procedure SMP02 – Safety Committee;

- Outputs from Procedure SMP03 – Safety Planning;

- Outputs from Procedure SMP04 – Preliminary Hazard Identification and Analysis;

- Outputs from Procedure SMP05 – Hazard Identification and Analysis;

- Outputs from Procedure SMP06 – Risk Estimation;

- Outputs from Procedure SMP07 – Risk and ALARP Evaluation;

- Outputs from Procedure SMP08 – Risk Reduction;

- Outputs from Procedure SMP09 – Risk Acceptance;

- Outputs from Procedure SMP10 – Safety Requirements and Contracts;

- Outputs from Procedure SMP11 – Hazard Log;

- Outputs from Procedure SMP12 - Safety Case and Safety Case Report.

This procedure should draw on information in the following documents, and it should also define changes that should be made to their content:

- Through-Life Management Plan;

- Integrated Test, Evaluation and Acceptance Plan;

- Project Safety Management Plan including RACI (Responsible, Accountable, Consulted, Informed) chart;

- Safety Management System Manuals of stakeholders (e.g. Delivery Teams, Delivery Teams providing sub-systems, Users, authorities responsible for safe storage, transportation, disposal, inspection, audit, incident investigation etc.);

- Customer/Supplier Agreements (or similar) defining interfaces and responsibilities for certain Safety Management activities.

Required Outputs

Safety Management System Documentation

The In-Service Safety Management System arrangements should be recorded in various places because of the many authorities involved. For instance, the Safety Management System manuals of different Delivery Teams, user authorities, contractors and support authorities should contain relevant information as well as other documents recording arrangements for Incident and Accident reporting and investigation.

The principal means of bringing together this information should be through the Safety Management Plan and its RACI chart, defining the involvement of the different authorities.

The Project Safety Case should contain a description of the In-Service Safety Management System in operation to ensure that the safety performance of the equipment is achieved and sustained through life.

Meet the Author

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.
#DefStanSafetyManagementSystem #EquipmentLifecycleSafety #InServiceSafetyManagement #MilitarySafetyProtocols #RiskManagementinService #SafetyCaseDocumentation #SafetyControlsMilitaryEquipment
Simon Di Nucci https://www.safetyartisan.com/?p=4133

Thursday, October 31, 2024

Monday, October 28, 2024

System Safety Risk Assessment

Learn about System Safety Risk Assessment with The Safety Artisan.

In this module, we're going to look at how we deal with the complexity of the real world. We do a formal risk analysis because real-world scenarios are complex. The Analysis helps us to understand what we need to do to keep people safe. Usually, we have some moral and legal obligation to do it as well. We need to do it well to protect people and prevent harm to people.

You Will Learn to:

- Explain what a system safety approach is and does; and

- Define what a risk analysis program is;

https://youtu.be/l3MLQQH7lxY

System Safety Risk Analysis.

Topics: System Safety Risk Assessment

Aim: How do we deal with real-world complexity?

- What is System Safety?

- The Need for Process;

- A Realistic, Useful, Powerful process:

- Context, Communication & Consultation; and

- Monitoring & Review, Risk Treatment.

- Required Risk Reduction.

Transcript: System Safety Risk Assessment

Click here for the Transcript on System Safety Risk Assessment

In this module, on System Safety Risk Assessment, we're going to look at how we deal with the complexity of the real world. We do a formal risk analysis because real-world scenarios are complex. The Analysis helps us to understand what we need to do to keep people safe. Usually, we have some moral and legal obligation to do it as well. We need to do it well to protect people and prevent harm to people.

What is System Safety?

To start with, here’s a little definition of system safety. System safety is the application of engineering and management principles, criteria, and techniques to achieve acceptable risk within a wider context. This wider context is operational effectiveness - We want our system to do something. That's why we're buying it or making it. The system has got to be suitable for its use. We've got some time and cost constraints and we've got a life cycle. We can imagine we are developing something from concept, from cradle to grave.

And what are we developing? We're developing a system. An organization of hardware, (or software) material, facilities, people, data and services. All these pieces will perform a designated function within the system. The system will work within a stated or defined operating environment. It will work with the intention to produce specified results.

We've got three things there. We've got a system. We've got the operating environment within which it works- or designed to work. And we have the thing that it's supposed to produce; its function or its application. Why did we buy it, or make, it in the first place? What's it supposed to do? What benefits is it supposed to bring humankind? What does it mean in the context of the big picture?

That's what a system is. I'm not going to elaborate on systems theory or anything like that. That's a whole big subject on its own. But we're talking about something complex. We're not talking about a toaster. It's not consumer goods. It's something complicated that operates in the real world. And as I say, we need to understand those three things - system, environment, purpose - to work out Safety.

We Need A Process

We've sorted our context. How is all this going to happen? We need a process. In the standard that we're going to look at in the next module, we have an eight-element process. As you can see there, we start with documenting our approach. Then we identify and document hazards. We document everything according to the standard so forget that.

We assess risk. We plan how we're going to mitigate the risk. We identify risk mitigation measures or controls as there are often known. Then we apply those controls to reduce risk. We verify and confirm that the risk reduction that we have achieved, or that we believe we will achieve. And then we got to get somebody to accept that risk. In other words, to say that it is an acceptable level of risk. That we can put up with this level of risk in exchange for the benefits that the system is going to give us. Finally, we need to manage risk through the entire lifecycle of the system until we finally get rid of it.

The key point about this is whatever process we follow, we need to approach it with rigor. We stick to a systematic process. We take a structured and rigorous approach to looking at our system.

And as you can see there from the arrows, every step in the eight-element sequence flows into the next step. Each step supports and enables the following steps. We document the results as we go. However, even this example is a little bit too simple.

A More Realistic Process

So, let's get a more realistic process. What we've got here are the same things we’ve had before. We've established the context at the beginning. Next, there’s risk assessment. Risk assessment consists of risk identification, risk analysis, and risk evaluation. It asks ‘Where are we?’ in relation to a yardstick or framework that categorizes risk. The category determines whether a risk is acceptable or not.

After determining whether the risk is acceptable or not, we may need to apply some risk treatment. Risk Treatment will reduce the risk further. By then we should have the risk down to an acceptable level.

So, that's the straight-through process, once through. In the real world, we may have to go around this path several times. Having treated the risk over a period of time, we need to monitor and review it. We need to make sure that the risk turns out, in reality, to be what we estimated it to be. Or at least no worse. If it turns out to be better- Well, that's great!

And on that monitoring and review cycle, maybe we even need to go back because the context has changed. These changes could include using the system to do something it was not designed to do. Or modifying the system to operate in a wider variety of environments. Whatever it might be, the context has changed. So, we need to look again at the risk assessment and go round that loop again.

And while we're doing all that, we need to communicate with other people. These other people include end-users, stakeholders, other people who have safety responsibilities. We need to communicate with the people who we have to work with. And we have to consult people. We may have to consult workers. We may have to consult the public, people that we put at risk, other duty holders who hold a duty to manage risk. That's our cycle. That's more realistic. In my experience as a safety engineer, this is much more realistic. A once-through process often doesn't cut it.

Required Risk Reduction

We're doing all this to drive risk down to an acceptable level. Well, what do we mean by that? Well, there are several different ways that we can do this, and I've got to illustrate it here. On the left-hand side of the slide, we have what's usually known as the ALARP triangle. It’s this thing that looks a bit like a carrot where the width of the triangle indicates the amount of risk. So, at the top of the triangle, we've got lots of risks. And if you're in the UK or Australia where I live, this is the way it's done. So there will be some level of risk that is intolerable. Then if the risk isn't intolerable, we can only tolerate it or accept it if it is ALARP or SFARP. And ALARP means that we've reduced the risk as low as reasonably practicable. And SFARP means so far as is reasonably practicable. Essentially, they’re the same thing - reasonably practical.

We must ensure that we have applied all reasonably practicable risk reduction measures. And once we've done so, if we're in this tolerable or acceptable region, then we can live with the risk. The law allows us to do that.

That's how it's done in the UK and Australia. But in other jurisdictions, like the USA, you might need to use a different approach. A risk matrix approach as we can see on the right-hand side of this slide. This particular risk matrix is from the standard we're about to look at. And we could take that and say, ‘We've determined what the risk is. There is no absolute limit on how much risk we can accept. But the higher the risk, the more senior level of sign-off from management we need’. In effect, you are prioritizing the risk. So you only bring the worst risks to the attention of senior management. You are asking ‘Will you accept this? Or are you prepared to spend the money? Or will you restrict the operational system to reduce the risk?’. This is good because it makes people with authority consider risks. They are responsible and need to make meaningful decisions.

In short, different approaches are legal in different jurisdictions.

Summary of Module

In Module Two, we've asked ourselves, ‘How can we deal with real-world complexity?’. And one way that's developed to do that is System Safety. System Safety is where we take a systematic approach to safety. This approach applies to both the system itself - the product - and the process of System Safety.

We address product and process. We need that rigorous process to give us confidence that what we've done is good enough. We have a realistic, useful and powerful process that enables us to put things in context. It helps us to communicate with everyone we need to, to consult with those that we have a duty to consult with. And also, we put around the basic risk process, this monitoring and review. And of course, we analyze risk to reduce it to acceptable levels. So we've got to treat the risk or reduce it or control it in some way to get it to those acceptable levels. In the end, it's all about getting that required risk reduction to work. That reduction makes the risk acceptable to expose human beings to, for the benefit that it will give us.

This is Module 2 of SSRAP

This is Module 2 from the System Safety Risk Assessment Program (SSRAP) Course. Risk Analysis Programs – Design a System Safety Program for any system in any application. You can access the full course here.

You can find more introductory lessons at Start Here.

#howtoriskassessment #howtoriskassessmentanalysis #learnriskassessment #learnriskassessmentanalysis #riskassess #riskassessment #riskassessmentanalysistechnique #riskassessmentanalysistraining #riskassessmentanalysistutorial #riskassessmenteducation #riskassessmentequation #riskassessmentguide #riskassessmentkeypoints #riskassessmentoutline #riskassessmentquestionstoask #riskassessmentskills #riskassessmenttechnique #riskassessmenttraining #riskassessmenttutorial #riskassessmentvideo #riskmanagement31000pdf

Simon Di Nucci https://www.safetyartisan.com/2021/03/13/ssrap-module-2-system-safety-risk-analysis/