Guidance on Safe Design

Want some good guidance on Safe Design? In this 52-minute video from the Safety Artisan, you will find it. I take the official guidance from Safe Work Australia. Then I provide some value-adding commentary on it, based on my 10+ years of experience working system safety under Australian WHS Law.



This guidance integrates seamlessly with Australian law and regulations, as it is designed to be consistent. However, it is genuinely useful in any jurisdiction.



A free video on 'Good Work Design' is available here.



https://youtu.be/OuarJA9n8PQ

This is the three-minute demo of the full, 52-minute-long video.



Get the video+ here



Topics: Safe Design



- A safe design approach;



- Five principles of safe design;



- Ergonomics and good work design;



- Responsibility for safe design;



- Product lifecycle;



- Benefits of safe design;



- Legal obligations; and



- Our national approach.



Transcript: Safe Design



Hello, everyone, and welcome to the Safety Artisan, where you will receive safety training via instructional videos on system safety, software safety, and design safety. Today I’m talking about design safety. What we’re going to be talking about is safe design, and this safe design guidance comes from Safe Work Australia. I’m showing you some text taken from the website and adding my own commentary and experience.



Topics



The topics that we’re going to cover today are - a safe design approach, five principles of safe design, ergonomics (more broadly, its human factors). Who has responsibility, doing safe design through the product lifecycle, the benefits of it, our legal obligations in Australia (but this is good advice wherever you are). Lastly, the Australian approach to improving safe design in order to reduce casualties in the workplace.



Introduction



The idea of safe design is it’s about integrating safety management, asset identification, and risk assessment early in the design process. We do this to eliminate or reduce risks throughout the life of a product,  whatever the product is, it might be a building, a structure, equipment, a vehicle or infrastructure. This is important because in Australia, in a five-year period, we suffered almost 640 work-related fatalities, of which almost 190 were caused by unsafe design or design-related factors contributed to that fatality. So, there’s an important reason to do this stuff, it’s not an academic exercise, we’re doing it for real reasons. And we’ll come back to the reason why we’re doing it at the end of the presentation.



A Safe Design Approach #1



First, we need to begin safe design right at the start of the lifecycle (we will see more of that later). It's at the beginning of the lifecycle when you're making your bad decisions about requirements. What do you want this system to do? How do we design it to do that? What materials and components and subsystems are we going to make or buy to put this thing together, whatever it is? Thinking about how we are going to construct it, maintain it, operate it, and then get rid of it at the end of life. There are lots of big decisions being made early in the life cycle. And sometimes these decisions are made accidentally because we don't consciously think about what we're doing. We just do stuff and then we realise afterwards that we've made a decision with sometimes quite serious implications.



A big part of my day job as a consultant was trying to help people think about those issues and make good decisions early on when it's still cheap, quick and easy to do. Because the more you've invested into a project, the more difficult it is to make changes. This is both from a financial point of view and if people have invested their time, sweat and tears into a project, they get very attached to it and they don't want to change it. There's an emotional investment made in the project.



The earlier you get in, at the feasibility stage let's say, and think about all of this stuff the easier it is to do it. A big part of that is where is this kit going to end up? What legislation codes of practice and standards do we need to consider and comply with? So that's the approach.



A Safe Design Approach #2



So, designers need to consider how safety can be achieved through the lifecycle. For example, can we design a machine with protective guarding so that the operator doesn't get hurt using it, but also so the machine can be installed and maintained? That's an important point as often to get at stuff we must take it apart and maybe we must remove some of those safety features. How do we then protect and maintain when the machine is maybe opened up, and the workings are things that you can get caught in or electrocuted by.



And how do we get rid of it? Maybe we've used some funky chemicals that are quite difficult to get rid of. In Australia, I suspect like many other places, we've got a mountain of old buildings that are full of asbestos, which is costing a gigantic sum of money to get rid of safely. we need to design a building which is fit for occupancy. Maybe we need to think about occupants that are not able bodied or they're moving stuff around in the building they don't want to and need a trolley to carry stuff around. we need access, we need sufficient space to do whatever it is we need to do.



This all sounds simple, obvious, doesn't it? So, let's look at these five principles. First of all, a lot of this you're going to recognise from the legal stuff, because the principles of safe design are very much tied in and integrated with the Australian legal approach, WHS, which is all good, all consistent and all fits together.



Five Principles of Safe Design



Principle 1: Persons with control. If you're making a decision that affects design and products, facilities or processes, it is your responsibility to think about safety, it's part of your due diligence (If you recall that phrase and that session).



Principle 2: We need to apply safe design at every stage in the lifecycle, from the very beginning right through to the end. That means thinking about risks and eliminating or managing them as early as we can but thinking forward to the whole lifecycle; sounds easy, but it’s often done very badly.



Principle 3: Systematic risk management. We need to apply these things that we know about and listen to other broadcasts from The Safety Artisan. We go on and on and on about this because this is our bread and butter as safety engineers, as safety professionals - identify hazards, assess the risk and think about how we will control the risks in order to achieve a safe design.



Principle 4: Safe design, knowledge and capability. If you're controlling the design, if you’re doing technical work or you're managing it and making decisions, you must know enough about safe design and have the capability to put these principles into practice to the extent that you need to discharge your duties. When I'm thinking of duties, I'm especially thinking of the health and safety duties of officers, managers and people who make decisions. You need to exercise due diligence (see the Work Health and Safety lessons for more about due diligence).



Principle 5: Information transfer. Part of our duties is not just to do stuff well, but to pass on the information that the users, maintainers, disposers, etc will need in order to make effective use of the design safely. That is through all the lifecycle phases of the product.



So those are the five principles of safe design, and I think they're all obvious, right? So, let's move on...



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!



Questions? Leave a Comment

#AustralianWHS #designwork #designworks #howtosafedesign #howtosafedesignanalysis #ineedsafety #inherentlysaferdesignprinciples #learnsafedesign #learnsafedesignanalysis #principlessafedesign #Safebydesignprinciples #safedesign #safedesignanalysistechnique #safedesignanalysistraining #safedesignanalysistutorial #safedesignprinciples #safedesigntechnique #safedesigntraining #safedesigntutorial #safedesignvideo #whatarethe5designprinciples #whatissafedesign

Simon Di Nucci https://www.safetyartisan.com/2020/05/26/safe-design-full/

Safety Concepts Part 1

In this 'Safety Concepts Part 1' Blog post, The Safety Artisan looks at the meaning of the term "safe". I look at an objective definition of safe - objective because it can be demonstrated to have been met.



This fundamental topic provides the foundation for all other safety topics, and it isn't complex. The basics are simple, but they need to be thoroughly understood and practiced consistently to achieve success.



https://youtu.be/IKAZ3KLsDW8

System Safety Concepts - highlights.



Get the full-length Lesson as part of the FREE Triple Learning Bundle.



Safety Concepts Part 1: Topics



- A practical (useful) definition of ‘safe’:



- What is risk?



- What is risk reduction?



- What are safety requirements?



- Scope:



- What is the system?



- What is the application (function)?



- What is the (operating) environment?



Safety Concepts Part 1: Transcript



Hi everyone and welcome to the Safety Artisan, where you will find professional, pragmatic, and impartial advice. Whether you want to know how safety is done or how to do it, I hope you’ll find today’s session helpful.



It’s the 21st of September 2019 as I record this. Welcome to the show. So, let’s get started. We’re going to talk today about System Safety concepts. What does it all mean?  We need to ask this question because it’s not obvious, as we will see.



If we look at a dictionary definition of the word ‘safe’, it’s an adjective: to be protected from or not exposed to danger or risk. Not likely to be harmed or lost. There are synonyms – protect, shield, shelter, guard, and keep out of harm’s way. They’re all good words, and I think we all know what we’re talking about. However, as a definition, it’s too imprecise. We can’t objectively say whether we have achieved safety or not.



A Practical Definition of ‘Safe’



What we need is a better definition, a more practical definition. I’ve taken something from an old UK Defence Standard. Forget about which standard, that’s not important. It’s just that we’re using a consistent set of definitions to work through basic safety concepts. And it’s important to do that because different standards, come from different legal systems and they have different philosophies. So, if you start mixing standards and different concepts together, that doesn’t always work.



OK so whatever you do, be consistent. That’s the key point. We’re going to use this set of definitions from the UK Defence Standard because they are consistent.



In this standard, ‘safe’ means: “Risk has been demonstrated to have been reduced to a level that is ALARP, and broadly acceptable or tolerable. And relevant prescriptive safety requirements have been met. For a system, in a given application, in a given Operating Environment.” OK, so let’s unpack that.



System Safety – Risk



So, we start with risk. We need to manage risk. We need to show that risk has been reduced to an acceptable level. As required perhaps by law, regulation, or a standard. Or just good practice in a particular industry. Whatever it is, we need to show that the risk of harm to people has been reduced. Not just any old reduction, we need to show that it’s been reduced to a particular level. Now in this standard, there are two tests for that.



And they’re both objective tests. The first one says as low as reasonably practicable. Basically, it’s asking have all reasonably practicable risk reduction measures have been taken. So that’s one test. And the second test is a bit simpler. It’s basically saying reduce the absolute level of risk to something that is tolerable or acceptable. Now don’t worry too much about precisely what these things mean. The purpose of today is to note that we’ve got an objective test to say that we’ve done enough.



System Safety – Requirements



So that’s dealt with risk. Let’s move on to safety requirements. If a requirement is relevant, then we need to apply it. If it’s prescriptive, if it says you must do this, or you must do that. Then we need to meet it. There are two separate parts to this ‘Safe’ thing: we’ve got to meet requirements; and, we’ve got to manage risk. We can’t use one as an excuse for not doing the other.



So just because we reduce risk until it’s tolerable or acceptable doesn’t mean that we can ignore safety requirements. Or vice versa. So those are the two key things that we’ve got to do. But that’s not actually quite enough to get us there. Because we’ve got to define what we’re doing, with what, and in what context. Well, we’re reducing the risk of a system. And the system might be a physical thing.



Defining the Scope: The System



It might be a vehicle, an airplane, a ship, or a submarine, it might be a car or a truck. Or it might be something a bit more intangible. It might be a computer program that we’re using to make decisions that affect the safety of human beings, maybe a medical diagnosis system. Or we’re processing some scripts or prescriptions for medicine and we’ve got to get it right. We could poison somebody. So, whether it’s a tangible or an intangible system.



We need to define it. And that’s not as easy as it sounds, because if we’re applying system safety, we’re doing it because we have a complex system. It’s not a toaster. It’s something a bit more challenging. Defining the system carefully and precisely is really important and helpful. So, we define what our system is, our thing, or our service. The system. What are we doing with it? What are we applying it to?



Defining the Scope: The Application



What are we using it for? Now, just to illustrate that no standard is perfect. Whoever wrote that defense standard didn’t bother to define the application. Which is kind of a major stuff-up to be honest, because that’s really important. So, let’s go back to an ordinary dictionary definition just to get an idea of what it means. By the way, I checked through the standard that I was referring to, and it does not explain it in this standard.



What it means by the application. Otherwise, I would use that by preference. But if we go back to the dictionary, we see application: the act of putting something into operation. OK, so, we’re putting something to use. We’re implementing, employing it, or deploying it maybe we’re utilizing it, applying it, executing it, enacting it. We’re carrying it out, putting it into operation, or putting it into practice. All useful words that help us to understand.



I think we know what we’re talking about. So, we’ve got a thing or a service. Well, what are we using it for? Quite obviously, you know a car is probably going to be quite safe on the road. Put it in water and it probably isn’t safe at all. So, it’s important to use things for their proper application, to the use to which they were designed. And then, kind of harking back to what I just said, the correct operating environment.



Defining the Scope: The Operating Environment



For this system, and the application to which we will put it to. So, we’ve got a thing that we want to use for something. What’s the operating environment in which it will be safe? What is it qualified or certified for? What’s the performance envelope that it’s been designed for? Typically, things work pretty well within the operating environment, within the envelope for which they were designed. Take them outside of that envelope and they perform not so well.



Maybe not at all. You take an airplane too high and the air is too thin, and it becomes uncontrollable. You take it too low and it smashes into the ground. Neither outcome is particularly good for the occupants of the airplane. Or whoever happens to be underneath it when it hits the ground. All of those three things:  what is the system? What are we doing with it? and where are we doing it? All those things have to be defined. Otherwise, we can’t really say that risk has been dealt with, or that safety requirements have been met.



System Safety: why Bother?



So, we’ve spent several slides just talking about what safe means, which might seem a bit over the top. But I promise you it is not, because having a solid understanding of what we’re trying to do is important in safety. Because safety is intangible. So, we need to understand what it is we’re aiming for. As some Greek bloke said, thousands of years ago: “If you don’t know to which port, you are bound, then no wind is favorable.”



It’s almost impossible to have a satisfactory Safety Program if you don’t know what you’re trying to achieve. Whereas, if you do have a precise understanding of what you’re trying to achieve, you’ve got a reasonably good chance of success. And that’s what it’s all about.



Copyright



Well, I’ve quoted you some information. From a UK government website. And I’ve done so in accordance with the terms of its Creative Commons license. More information about the terms of that can be found on this page.



End: Safety Concepts Part 1



If you want more, if you want to unpack all the Major Definitions, all the system safety concepts that we're talking about, then there's the second part of this video, which you can see here.



I hope you enjoy it. Well, that's it for the short video, for now. Please go and have a look at the longer video to get the full picture. OK, everyone, it's been a pleasure talking to you and I hope you found that useful. I'll see you again soon. Goodbye.



Back to the Start Here Page. Get the full-length Lesson as part of the FREE Triple Learning Bundle.



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.

#definitionofsafe #definitionofsafety #definitionofsafetyengineering #definitionofsafetyhazard #definitionofsafetyincident #definitionofsafetymanagementsystem #definitionofsafetymeasures #definitionofsafetyprecautions #definitionofsafetyrisk #howwouldyoudefinesafety #meaningofsafe #meaningofsafety #safemeaning #safetyconcepts #whataretheimportanceofsafetymeasures #whatdoessafetymeasuresmean #whatdoesthewordsafetymeantoyou #whatissafe #whatsafemeans

Simon Di Nucci https://www.safetyartisan.com/2019/09/22/safety-concepts-part-1/

Courses

Here are some of the courses that you can buy:



- Free Triple Bundle;



- Five Ways to Identify Hazards;



- Identify and Analyze Functional Hazards;



- Foundations of System Safety;



- Principles-of-Safe-Software; and



- System-Safety-Assessment-with-Mil-Std-882E.



Free Triple Bundle



https://youtu.be/IKAZ3KLsDW8

Highlights from one of the Triple Bundle Resources



Free Triple Bundle Resources:



- Risk Management 101 Course,



- Preliminary Hazard Identification & Analysis Guide,



- System Safety Concepts Course,



- System Safety Principles Course,



- 23 Lessons / Three hours of downloadable Video, and



- Resources: slide decks & transcripts.



get it for free



Five Ways to Identify Hazards - $45 (US)



https://youtu.be/A83QwHgHF6M

Introduction to the Bonus Webinar



In this course, learn how to perform Preliminary Hazard Identification. It includes video lessons, examples, and downloadable resources:



- Introduction,



- Preliminary Hazard Identification (Task 201 of Mil-Std-882E),



- Resources - slide decks and transcripts,



- Bonus Webinar: Five Ways to Identify Hazards, and



- Full downloadable lesson video.



- 19 Lessons / Two Hours of Video Content.



get it here



Identify and Analyze Functional Hazards - $125 (US)



https://youtu.be/RZEa18PKXcY

Introduction to the Bonus Webinar



This course has 11 lessons (2.5 hours of video content) in four major parts:



- Webinar overview - putting the Tasks together,



- Preliminary Hazard Identification (Task 201 of Mil-Std-882E),



- Functional Failure Analysis Theory & Worked Example, and



- Functional Hazard Analysis (Task 208 of Mil-Std-882E).



get it here



Foundations of System Safety - $180 (US)



https://youtu.be/Az4B4hFpVP4

Introduction to the Webinar



In this course, I pull together the three tasks that lay the foundations of every system safety program.  The contents are:



- Introduction,



- Preliminary Hazard Identification (Task 201 of Mil-Std-882E),



- Preliminary Hazard Analysis (Task 202 of Mil-Std-882E),



- System Requirements Hazard Analysis (Task 203 of Mil-Std-882E),



- Safety Analysis Techniques Overview - how to put the Tasks together,



- 18 Lessons / Four Hours of Video Content, and



- Downloads, slide decks & transcripts.



get it here



Principles of Safe Software - $245 (US)



https://youtu.be/g-5mlNIk14I

Just One of the Lessons from Principles of Safe Software.



Software safety can be a daunting subject. Software development is challenging and, as you will see, it is a very risky business. Safety is also an intangible, emergent property: how do we develop safe software? Find out here:



- Introduction,



- Software Development Facts,



- Software Safety Facts,



- Safe Software Principles,



- Overview of Software Standards,



- RTCA DO-178 (ED-12),



- IEC 61508,



- ISO 26262,



- Review of Standards,



- Lessons Learned,



- 11 Lessons / 2.5 Hours of Video Content, and



- Downloads, slide decks & transcripts.



get it here



Courses: System Safety Assessment with Mil-Std-882E - $545 (US)



https://youtu.be/nuDtDhm3i-I

Welcome to the System Safety Assessment Course.



Design a Safety Risk Assessment Program for ANY system in ANY application. This course covers all ten of the analysis tasks from the defense system safety standard Mil-Std-882E.



Whatever it is, you will learn how to tailor your risk assessment, using the analyses you need. You will be able to meet your legal and regulatory requirements. Once you’ve learned how to do this, you can apply it to almost any system.  There are thirteen lessons:



- Introduction to the Course,



- The System Safety Process,



- Tailoring your System Safety Assessment Program,



- Preliminary Hazard Identification (Task 201),



- Preliminary Hazard Analysis (Task 202),



- System Requirements Hazard Analysis (Task 203),



- Sub-system Hazard Analysis (Task 204),



- System Hazard Analysis (Task 205),



- Operating and Support Hazard Analysis (Task 206),



- Health Hazard Analysis (Task 207),



- Functional Hazard Analysis (Task 208),



- System of Systems Hazard Analysis (Task 209), and



- Environmental Hazard Analysis (Task 210).



get the complete course



You can also get all of the webinars at the Safety Engineering Academy, which gives you access to recorded webinars, a private community of like-minded people, and other resources. There are 51 videos so far, and new ones are being added every month.



Back to home.



Simon Di Nucci https://www.safetyartisan.com/courses/

Proportionality

Proportionality is about committing resources to the Safety Program that are adequate - in both quality and quantity - for the required tasks.



Introduction to Proportionality



Proportionality is a concept that should be applied to determine the allocation of resource and effort to a safety and environmental argument based on its risk.  It is a difficult concept to attempt to distil into a process as each Product, System or Service will have different risks, objectives, priorities and interfaces that make a ‘one size fits all’ approach impossible.



This section describes an approach that may be used to assist in applying the concept of proportionality; it seeks to guide you in understanding where a proportionate amount of effort can be directed, while at the same time maintaining the overriding principle that Risk to Life must be managed.  Regulators require that a proportional approach is used and there are many methods that try to achieve this.  Some focus on the amount of evidence needed to justify a safety argument; some provide more emphasis on the application of activities that are required to make a safety argument and some consider that fulfilling certain criteria can lead to an assessment of risk, but one requirement that is at the centre of any proportional approach is that safety risks are acceptable. 



A fundamental consideration of a proportional approach is considering compliance against assessment criteria.  The Health and Safety Executive’s view is that there should be some proportionality between the magnitude of the risk and the measures taken to control the risk. The phrase “all measures necessary” should be interpreted with this principle in mind. Both the likelihood of accidents occurring and the severity of the worst possible accident determine proportionality.  Application of proportionality should highlight the hazardous activities for which the Duty Holder should provide the most detailed arguments to support the demonstration .



The following considerations may affect proportionality, in a defence context:



- Type of consequence;

- Severity;

- The stage in the Life cycle;

- Intended use (CON OPS/Design Intent);

- Material state (degradation);

- Historical performance;

- Cost of safety;

- Cost of realising risk;

- Public Relations;

- Persons at Risk:- 1st,2nd,3rd Party;

- Military

- Civilian;

- Civil Servants;

- Contractors;

- General public;

- VIPs;

- Youths;

- Volume;

- Geographical spread/transboundary.



Some important points that should be noted regarding safety and environmental proportionality approach are that:



- Proportionality is inherent to safety and environmental risk assessment (i.e. use of ALARP, BPEO, etc.);

- Proportionality is explicitly linked to risk;

- Multiple factors need to be considered when deciding a proportional approach;

- ASEMS is the mandated safety and environmental framework; therefore, the framework should be applied; it is not possible to develop a proportional approach that negates any part of ASEMS.



Waterfall Approach Process



The model that should be used to consider a proportional approach is intended to provide guidance and should only be used by competent safety and environmental practitioners.  A degree of judgement should be used when answering questions, particularly where a Product, System or Service may easily be classified in more than one category; this is why the use of competent safety and environmental practioners is required.



The waterfall approach model categorises Product, System or Service risk in accordance with factual questions, presented on the left of the diagram below, which are asked about the intended function and operation.  Each question should be used to define the cumulative potential risk, which may be presented by the Product, System or Service.  The Product, System or Service is categorised into one of three risk bands, which align to those defined in the Tolerability triangle, presented in the right of of the diagram.



During the process two initial questions are asked, where an answer of “yes” will automatically result in a categorisation of high risk, regardless of the answer to subsequent questions.  Further refinement is required for lower risk systems to ensure that the system risk is categorised appropriately.



Figure 1, Proportionality Waterfall Approach Model



The diagram above depicts the proportionality waterfall approach model used for the application of ASEMS.



Adherence to ASEMS is mandatory for DE&S.  As such, it is not possible to develop a proportional approach that negates any individual part of ASEMS and so the procedures described in ASEMS Part 2 - Instructions, Procedures and Support should be followed;  where proportionality may be applied is within each General Management Procedure, Safety Management Procedure or Environmental Management Procedure for the allocation of resource, time or effort.



Once the risk category has been established guidance is defined which prescribes the rigour which should be applied to the safety assessment process in terms of Process, Effort, Competence, Output, Assurance (PECOA):



- Process - the amount of dedicated/specific process, level of intervention in the organisational structure the Safety and Environmental Management System are established;

- Effort - How much time is afforded to the management of risk;

- Competence - the level of competence that is required to conducted appropriate assessment and management of safety and environmental;

- Output - The detail of evidence and reporting is cognisant to the level of risk;

- Assurance - The level of assurance required which shall be applied to the process.



Guidance for the application of PECOA is provided in the table below.  It should be noted that this is indicative guidance for illustrative purposes only. It is a fundamental requirement of ASEMS safety management principles that all safety decisions made should be reviewed, assessed and endorsed by a Safety and Environmental Management Committee to ensure that the Products, Systems and Services categorisation is correct. The diagram below shows the process that may be applied:



Proportionality Process



It should be remembered that using this low/medium and high categorisation could be misleading as the model takes no account of the population or rate of occurrence of the harm. A simple system that can only cause minor injury could still have a high degree of risk if there are lots of people exposed to the risk and the accident rate was high.  Moreover, acceptance of such a situation could lead to the development of an ineffective safety culture or the bypassing of safety mitigation procedures in order to avoid a high accident/minor injury position.  This is where the application of competent safety and environmental advice is essential to ensure that any proportionality model is not slavishly followed at the expense of proper rigour.   Where this model is useful is assisting those safety and environmental professionals to perform a preliminary assessment regarding what Products, Systems or Services are a priority for the allocation of resource, time or effort.



Stage One - System type and Life Cycle Phase



The first question is used to indicate, at a high level, the likely degree of risk for a project.  It should be noted that this is not a definitive assessment and that Products, Systems or Services could move within the model as the safety or environmental evidence is assessed.  There will be a degree of pre-existing assessment which accompanies a Product, System or Service and this may be used to assist with this initial question. 



The safety and environmental assessment process should be closely aligned with the Product, System or Service development process for newly developed Product, System or Services.  Where Products, Systems or Services are in the Concept, Assessment, Development or Manufacture phase of the CADMID/T cycle, they should be accompanied by a safety and environmental assessment process which utilises quantitative assessment techniques.



Where a Product, System or Service sits in the CADMID/T cycle should not influence the rigour of any safety or environmental argument; this model is provided to assist with any determination of the resource, time or effort that may be applied to the evidence to support the argument.  All Risk to Life should be ALARP, with no exception; what changes is the allocation of resources, time and effort to reach that judgement.



Those Products, Systems or Services where the expected worst credible consequence results in, at worst, a single minor injury should automatically be categorised as LOW risk and a qualitative approach may be adopted.



Commercial Off The Shelf or Military Off The Shelf systems should be accompanied by evidence which may be used in the safety and environmental assessment to demonstrate that they are acceptably safe and environmentally compliant, particularly where these are manufactured for use in the EU, where each Product, System or Service should demonstrate compliance with the applicable EU standards.  That the Product, System or Service is Commercial Off The Shelf or Military Off The Shelf is not, in itself, evidence.



Such evidence should include test evidence, trials evidence or a certificate of conformance.  Where a Commercial Off The Shelf or Military Off the Shelf system is already in the in-service phase and it is established that there is sufficient evidence to form a compelling safety argument that the Risk to Life is ALARP, then the system should be categorised as MEDIUM-LOW.  Where the system is also non-complex then it may be categorised as LOW.



Such Commercial Off The Shelf or Military Off the Shelf evidence should only be relied upon where it is established that this evidence is sufficient to demonstrate that the system is acceptably safe and environmentally compliant and already in existence.  The degree and appropriateness of evidence should be established by a Safety and Environmental Management Committee, with particular emphasis upon the quality of the evidence for high-risk systems.  This approach should be undertaken if the Product, System or Service in its entirety is categorised as Commercial Off The Shelf or Military Off the Shelf.  Where only sub-systems or components are Commercial Off The Shelf or Military Off the Shelf, the Product, System or Service should be categorised as bespoke and assessed accordingly.



Stage Two - Risk estimation and System Complexity



Any estimation of the risk that a Product, System or Service is likely to present should be used to further refine its categorisation.  If the worst credible consequence of a Product, System or Service is multiple fatalities then that Product, System or Service should automatically be categorised as HIGH risk.



If the worst credible consequence is a single fatality or multiple severe injuries then the system complexity should be considered further to refine and inform the categorisation.  Complex or novel system designs should have a higher degree of Suitably Qualified Experienced Personnel to conduct the safety and environmental assessment.  Accordingly, those Products Systems or Services which are complex and novel should also be categorised as HIGH whereas those exhibiting a lower degree of complexity might be categorised as MEDIUM.



Notwithstanding this, those Products, Systems or Services thatare in the Concept, Assessment, Development or Manufacture/Termination phase of the CADMID/T cycle should still be supported by a quantitative safety and environmental process.  The only exceptions are those Products, Systems or Services where the worst credible consequence is a single minor injury.  These should be categorised as LOW risk and may be supported by a qualitative safety and/or environmental process.



LOW risk Products, Systems or Services were the worst credible consequence is at worst a single minor injury should be categorised as LOW-MEDIUM risk where the design is complex or novel, those exhibiting a lower degree of complexity should be categorised as LOW risk.



Once the risk category has been established the rigour which should be applied to the safety assessment process in terms of Process, Effort, Competence, Output, Assurance (PECOA) should be defined.  This is summarised below:



Program ScaleLifecycle StageSmall scale or no Critical FunctionCADMID/TCADMID/TCADMID/TLarge Scale Capital,Critical Function or bespokeCADMID/TCADMID/TCADMID/TAssessmentHighMediumLowProcessA rigorous quantitative safety and environmental assessment process should be applied.Consideration should be given to the application of a qualitative safety and environmental assessment process.  Functional safety/environmental assessment may be required, if identified as a risk control measure.A qualitative safety and environmental assessment process should be appropriate for low risk, low complexity systems.EffortSignificant effort should be expended developing the safety and environmental case.A medium level of effort should apportioned to development of the safety and environmental case, increasing for newly developed systems.A medium level of effort should be apportioned to development of the safety and environmental case.CompetenceThe safety and environmental assessment and assurance programme should be led by individuals who are experts.  Remaining personnel should be at least Practitioners who should be provided with oversight where appropriate.Personnel engaged in the safety and environmental assessment and approval should be at least practitioners.Personnel engaged in the safety and environmental assessment and approval should be at least supervised practitioners who should be provided with oversight where appropriate.OutputA safety and environmental case should be developed which includes a safety argument.  The safety assessment process should be substantiated by quantitative evidence.A safety and environmental case should be developed, which should include a safety and environmental argument for all by simplex low risk systems.  The safety assessment process should be substantiated by quantitative evidence for newly developed systems.A safety and environmental statement may be considered for systems, which are low risk and complexity.AssuranceThe safety and environmental assessment should be independently assured.Independent assurance should be considered and applied to those projects which are considered to be novel or complex.  Assurance may be conducted at Committee level. Independent assurance is not required.ASEMS GuidanceSafety and Environmental   Dedicated tailored and full implementation of all Clauses, articulated through adherence to all GMPs, SMPs and EMPs.Safety and Environmental   Apply full implementation of all Clauses, in line with guidance provided for the Functional safety/environmental assessment, as required, if identified as a risk control measure and application of GMPs, SMPs and EMPs.Where Project Teams have an overarching Safety and Environmental Management Systems in place:   Safety Gather sufficient evidence to support safety argument and document in a Safety Case/Assessment in accordance with SMP 04, 05, 06, 09 and 12     Environmental Gather sufficient information in order to produce Environmental Impact Statement in accordance with EMP 07 - Environmental Reporting.



Process



The type of safety and environmental process which should be applied is dependent both upon the Product System or Service categorisation and the phase of the CADMID/T cycle that the project is in.  Newly developed MEDIUM-LOW to HIGH category Products, Systems or Services which are in the Concept, Assessment, Development or Manufacture phase of the cycle should have a quantitative safety and environmental assessment process applied, the depth and rigour of the assessment should be proportionate to its classification.  LOW risk Products, Systems or Services where the worst credible consequence is anticipated to be no greater than one minor injury may be assessed qualitatively.



A qualitative safety and environmental assessment process should be applied to Products, Systems or Services, which are in the In-Service, Disposal/Termination phase where it is deemed that there is sufficient evidence already in existence to demonstrate that it is acceptably safe.  In these circumstances a qualitative safety and environmental process should be applied to assess the in-service risks.



The approach uses a systematic and logical approach to categorise the resource, time and effort required to support any argument that a Product, System or Service is acceeptably safe or provides no significant damage to teh environment.  It also advocates the application of ASEMS in its entirety, prescribing the level of rigour, which should be applied in terms of process, effort, competence, output and assurance.



Effort



The effort apportioned to the safety and environmental process should be proportionate to the classification of the system.  A significant amount of rigour should be applied to those projects requiring quantitative assessment processes, particularly those with the highest degree of risk and complexity.



If a Product System or Service is assessed to be in a particularly low category and is simple it may not be necessary to undertake the full scope of risk management procedures.  In these circumstances a certificate of conformance may be sufficient, which may be supported by statement to that effect from the Safety and Environmental Management Committee.



All decisions made regarding the evidence required to justify a safety argument (regardless of risk) should be endorsed by a Safety and Environmental Management Committee.  If this is decision is delegated further for those Products, Systems or Services that are low risk is for the Duty Holder to determine as all decisions regarding to Risk to Life are made on their behalf.



Competence



The safety and environmental lead should be an expert for HIGH category projects or for MEDIUM category projects where the Product System or Service is particularly complex or a novel design.  The remaining personnel engaged on such projects should be at least practitioner level.  A competency assessment should be undertaken which should be endorsed by a Safety and Environmental Management Committee.



The safety and environmental lead for MEDIUM category projects should be at least practitioner level.  The remaining personnel engaged on such projects should be practitioner or supervised practitioner where appropriate supervision is in place.  A competency assessment should be undertaken which should be endorsed by a Safety and Environmental Management Committee.



The safety and environmental lead for LOW category projects should be at least practitioner level or a supervised practitioner with appropriate supervision in place.



Competency requirements relating to specific safety and environmental processes defined in ASEMS should be applied where those processes are undertaken.



Output



A safety and environmental case should be developed for HIGH category projects which includes a safety and environmental argument, developed using Claims Arguments Evidence (CAE) or Goal Structuring Notation (GSN).  The argument should be substantiated by quantitative evidence such as reliability data or the output from quantitative safety assessment processes.



A safety and environmental case should be developed for MEDIUM category projects which includes a CAE or GSN safety argument.  The quality and depth of evidence required to substantiate the safety and environmental argument should be proportionate to the classification of the Product System or Service.   Products, Systems or Services with increased complexity or higher degrees of risk should be substantiated by quantitative evidence



A Safety and environmental case should be developed for MEDIUM-LOW category Products, Systems or Services. 

#enoughsafe #enoughsafety #howmuchdoessafetycost #howoftenshouldasafetyandhealthprogrambeevaluated #isitsafeisitsafe #issafetyimportant #knowingsafetyisnotenoughpracticeit #safesafetysafely #safetyandcost #safetycost #safetycostbenefitanalysis #safetyeffort #whenenoughisenough #whyismaintainingasafeworkenvironmentimportant #whysafetyissoimportant

Simon Di Nucci https://www.safetyartisan.com/2022/09/14/proportionality/

Sub-System Hazard Analysis with Mil-Std-882E
In this video lesson, I look at Sub-System Hazard Analysis with Mil-Std-882E (SSHA, which is Task 204). I teach the mechanics of the task, but not just that. I'm using my long experience with this Standard to teach a pragmatic approach to getting the work done.

Task 204 is one of three tasks that integrate tightly in a Systems Engineering framework. (The others are System Hazard Analysis, Task 205, and System of Systems Hazard Analysis, Task 209.)

SSHA is designed to be used where a formal Sub-System Specification (SSS) has been created. However, an SSS is not essential to perform this Task. The need for SSHA is usually driven by the complexity of the system and/or that sub-system development is contracted out.

Together, we will explore Task 204's aim, description, scope, and contracting requirements. There's value-adding commentary, and I explain the issues with SSHA - how to do it well and avoid the pitfalls.

https://youtu.be/VUreppOMyiQ
This is the seven-minute demo, the full video is 40-minutes' long.

buy the course here

Topics: Sub-System Hazard Analysis

- Preamble: Sub-system & System HA.

- Task 204 Purpose:

- Verify subsystem compliance;

- Identify (new) hazards; and

- Recommend necessary actions.

- Task Description (six slides);

- Reporting;

- Contracting; and

- Commentary.

Transcript: Sub-System Hazard Analysis

Introduction

Hello, everyone, and welcome to the Safety Artisan, where you will find professional, pragmatic, and impartial instruction on all things system safety. I'm Simon – I’m your host for today, as always and it's the fourth of April 22. With everything that's going on in the world, I hope that this video finds you safe and well.

Sub-System Hazard Analysis

Let's move straight on to what we're going to be doing. We're going to be talking today about subsystem hazard analysis and this is task 204 under the military standard 882E. Previously we've done 201, which was preliminary hazard identification, 202, which is preliminary hazard analysis, and 203, which is safety requirements hazard analysis. And with task 204 and task 205, which is system has analysis, we're now moving into getting stuck into particular systems that we're thinking about, whether they be physical systems or intangible. We’re thinking about the system under consideration and I'm really getting into that analysis.

Topics for this Session

So, the topics that we're going to cover today, I've got a little preamble to set things in perspective. We then get into the three purposes of task 204. First, to verify compliance. Secondly, to identify new hazards. And thirdly, to recommend necessary actions. That would be recommended control measures for hazards and risks. We've got six slides of task description, a couple of slides on reporting, one on contracting, and then a few slides on some commentary where I put in my tuppence worth and I'll hopefully add some value to the basic bones of the standard.

It's worth saying that you'll notice that subsystem is highlighted in yellow and the reason for that is that the subsystem and system hazard analysis tasks are very, very similar. They're identical except for certain passages and I've highlighted those in yellow. Normally I use a yellow highlighter to emphasize something I want to talk about. This time around, I'm using underlining for that and the yellow is showing you what these are different for subsystem analysis as opposed to system . And when you've watched both sessions on 204 and 205, I think you'll see the significance of what I've done.

Preamble – Sub-system & System HA

Before we get started, we need to explain the system model that the 882 is assuming. If we look at the left-hand side of the hexagons, we've got our system in the center, which we're considering. Maybe that interfaces with other systems. They work within the operating environment; hence we have the icon of the world, and the system and maybe other systems are there for a purpose. They’re performing some task; they’re doing some function and that's indicated by the tools. We're using the system to do something, whatever it might be.

Then as we move to the right-hand side, the system is itself broken down into subsystems. We’ve got a couple here. We've got sub-systems A and B and then A further broken down into A1 and A2, for example. There's some sort of hierarchy of subsystems that are coming together and being integrated to form the overall system. That is the overall picture that I'd like to bear in mind while we're talking about this. The assumption in the 882, is we're going to be looking at this subsystem hierarchy bottom upwards, largely. We'll come on to that.

Sub-System Hazard Analysis (T204)

The purpose of the task, as I've said before, it's threefold. We must verify subsystem compliance with requirements. Requirements to deal with risk and hazards. We must identify previously unidentified hazards that may emerge as we're working at a lower level now. And we must recommend actions as necessary. Those are further requirements to eliminate all hazards or mitigate associated risks. We'll keep those three things in mind and that will keep coming up.

End: Sub-System Hazard Analysis

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!

You can find a free pdf of the System Safety Engineering Standard, Mil-Std-882E, here.
#hazardanalysistraining #hazardanalysistutorial #Milstd882Technique #Milstd882Training #Milstd882tutorial #Milstd882Video #MilStd882E #Milstd882eTechnique #Milstd882eTraining #Milstd882etutorial #Milstd882eVideo #safetyengineertraining #SafetystandardTechnique #SafetystandardTraining #Safetystandardtutorial #SafetystandardVideo #SSHA #subsystemhazardanalysis #SubsystemhazardanalysisTechnique #SubsystemhazardanalysisTraining #Subsystemhazardanalysistutorial #SubsystemhazardanalysisVideo #SystemsafetyengineeringTechnique #systemsafetyengineeringtraining #Systemsafetyengineeringtutorial #SystemsafetyengineeringVideo #Task204
Simon Di Nucci https://www.safetyartisan.com/?p=547

Sub-System Hazard Analysis with Mil-Std-882E
In this video lesson, I look at Sub-System Hazard Analysis with Mil-Std-882E (SSHA, which is Task 204). I teach the mechanics of the task, but not just that. I'm using my long experience with this Standard to teach a pragmatic approach to getting the work done.

Task 204 is one of three tasks that integrate tightly in a Systems Engineering framework. (The others are System Hazard Analysis, Task 205, and System of Systems Hazard Analysis, Task 209.)

SSHA is designed to be used where a formal Sub-System Specification (SSS) has been created. However, an SSS is not essential to perform this Task. The need for SSHA is usually driven by the complexity of the system and/or that sub-system development is contracted out.

Together, we will explore Task 204's aim, description, scope, and contracting requirements. There's value-adding commentary, and I explain the issues with SSHA - how to do it well and avoid the pitfalls.

https://youtu.be/VUreppOMyiQ
This is the seven-minute demo, the full video is 40-minutes' long.

buy the course here

Topics: Sub-System Hazard Analysis

- Preamble: Sub-system & System HA.

- Task 204 Purpose:

- Verify subsystem compliance;

- Identify (new) hazards; and

- Recommend necessary actions.

- Task Description (six slides);

- Reporting;

- Contracting; and

- Commentary.

Transcript: Sub-System Hazard Analysis

Introduction

Hello, everyone, and welcome to the Safety Artisan, where you will find professional, pragmatic, and impartial instruction on all things system safety. I'm Simon – I’m your host for today, as always and it's the fourth of April 22. With everything that's going on in the world, I hope that this video finds you safe and well.

Sub-System Hazard Analysis

Let's move straight on to what we're going to be doing. We're going to be talking today about subsystem hazard analysis and this is task 204 under the military standard 882E. Previously we've done 201, which was preliminary hazard identification, 202, which is preliminary hazard analysis, and 203, which is safety requirements hazard analysis. And with task 204 and task 205, which is system has analysis, we're now moving into getting stuck into particular systems that we're thinking about, whether they be physical systems or intangible. We’re thinking about the system under consideration and I'm really getting into that analysis.

Topics for this Session

So, the topics that we're going to cover today, I've got a little preamble to set things in perspective. We then get into the three purposes of task 204. First, to verify compliance. Secondly, to identify new hazards. And thirdly, to recommend necessary actions. That would be recommended control measures for hazards and risks. We've got six slides of task description, a couple of slides on reporting, one on contracting, and then a few slides on some commentary where I put in my tuppence worth and I'll hopefully add some value to the basic bones of the standard.

It's worth saying that you'll notice that subsystem is highlighted in yellow and the reason for that is that the subsystem and system hazard analysis tasks are very, very similar. They're identical except for certain passages and I've highlighted those in yellow. Normally I use a yellow highlighter to emphasize something I want to talk about. This time around, I'm using underlining for that and the yellow is showing you what these are different for subsystem analysis as opposed to system . And when you've watched both sessions on 204 and 205, I think you'll see the significance of what I've done.

Preamble – Sub-system & System HA

Before we get started, we need to explain the system model that the 882 is assuming. If we look at the left-hand side of the hexagons, we've got our system in the center, which we're considering. Maybe that interfaces with other systems. They work within the operating environment; hence we have the icon of the world, and the system and maybe other systems are there for a purpose. They’re performing some task; they’re doing some function and that's indicated by the tools. We're using the system to do something, whatever it might be.

Then as we move to the right-hand side, the system is itself broken down into subsystems. We’ve got a couple here. We've got sub-systems A and B and then A further broken down into A1 and A2, for example. There's some sort of hierarchy of subsystems that are coming together and being integrated to form the overall system. That is the overall picture that I'd like to bear in mind while we're talking about this. The assumption in the 882, is we're going to be looking at this subsystem hierarchy bottom upwards, largely. We'll come on to that.

Sub-System Hazard Analysis (T204)

The purpose of the task, as I've said before, it's threefold. We must verify subsystem compliance with requirements. Requirements to deal with risk and hazards. We must identify previously unidentified hazards that may emerge as we're working at a lower level now. And we must recommend actions as necessary. Those are further requirements to eliminate all hazards or mitigate associated risks. We'll keep those three things in mind and that will keep coming up.

End: Sub-System Hazard Analysis

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!

You can find a free pdf of the System Safety Engineering Standard, Mil-Std-882E, here.
#hazardanalysistraining #hazardanalysistutorial #Milstd882Technique #Milstd882Training #Milstd882tutorial #Milstd882Video #MilStd882E #Milstd882eTechnique #Milstd882eTraining #Milstd882etutorial #Milstd882eVideo #safetyengineertraining #SafetystandardTechnique #SafetystandardTraining #Safetystandardtutorial #SafetystandardVideo #SSHA #subsystemhazardanalysis #SubsystemhazardanalysisTechnique #SubsystemhazardanalysisTraining #Subsystemhazardanalysistutorial #SubsystemhazardanalysisVideo #SystemsafetyengineeringTechnique #systemsafetyengineeringtraining #Systemsafetyengineeringtutorial #SystemsafetyengineeringVideo #Task204
Simon Di Nucci https://www.safetyartisan.com/?p=547

System Hazard Analysis with Mil-Std-882E
In this 45-minute session, I look at System Hazard Analysis with Mil-Std-882E. SHA is Task 205 in the Standard. I explore Task 205's aim, description, scope, and contracting requirements.

I also provide commentary, based on working with this Standard since 1996, which explains SHA. How to use it to complement Sub-System Hazard Analysis (SSHA, Task 204). How to get the maximum benefits from your System Safety Program.

Using Task 205 effectively is not just a matter of applying it in number order with the other Tasks. We need to use it within the Systems Engineering framework. That means using it top-down, to set requirements, and bottom-up to verify that they are met.

https://youtu.be/F70fhSGsyLk
This is the seven-minute-long demo. The full video is 47 minutes long.

get the course 'system hazard analysis': click here

System Hazard Analysis: Topics

- Task 205 Purpose ;

- Verify subsystem compliance;

- ID hazards (subsystem interfaces and faults);

- ID hazards (integrated system design); and

- Recommend necessary actions.

- Task Description (five slides);

- Reporting;

- Contracting; and

- Commentary.

Transcript: System Hazard Analysis with Mil-Std-882E

Introduction

Hello, everyone, and welcome to the Safety Artisan, where you will find professional, pragmatic, and impartial safety training resources and videos. I’m Simon, your host, and I’m recording this on the 13th of April 2020. And given the circumstances when I record this, I hope this finds you all well.

System Hazard Analysis Task 205

Let's get on to our topic for today, which is System Hazard Analysis. Now, system hazard analysis is, as you may know, Task 205 in the Mil-Std-882E system safety standard.

Topics for this Session

What we're going to cover in this session is purpose, task description, reporting, contracting, and some commentary – although I'll be making commentary all the way through. Going back to the top, the yellow highlighting with this (and with Task 204), I'm using the yellow highlighting to indicate differences between 205 and 204 because they are superficially quite similar. And then I'm using underlining to emphasize those things that I want to bring to your attention and emphasize.

Within Task 205, Purpose. We've got four purpose slides for this one. Verify subsistent compliance and recommend necessary actions – fourth one there. And then in the middle of the sandwich, we've got the identification of hazards, both between the subsystem interfaces and faults from the subsystem propagating upwards to the overall system and identifying hazards in the integrated system design. So, quite a different emphasis to 204, which was thinking about subsystems in isolation. We’ve got five slides of task description, a couple on reporting, one on contracting – nothing new there – and several commentaries.

System Requirements Hazard Analysis (T205)

Let's get straight on with it. The purpose, as we've already said, there is a three-fold purpose here; Verify system compliance, hazard identification, and recommended actions, and then, as we can see in the yellow, the identifying previously unidentified hazards is split into two. Looking at subsystem interfaces and faults and the integration of the overall system design. And you can see the yellow bit, that's different from 204 where we are taking this much higher-level view, taking an inter-subsystem view and then an integrated view.

Task Description (T205) #1

On to the task description. The contract has got to do it and document, as usual, looking at hazards and mitigations, or controls, in the integrated system design, including software and human interface. We must come onto that later.

All the usual stuff about we've got to include COTS, GOTS, GFE, and NDI. So, even if stuff is not being developed, if we're putting together a jigsaw system from existing pieces, we've still got to look at the overall thing. And as with 204, we go down to the underlined text at the bottom of the slide, areas to consider. Think about performance, and degradation of performance, functional failures, timing and design errors, defects, inadvertent functioning – that classic functional failure analysis that we've seen before.

Again, while conducting this analysis, we’ve got to include human beings as an integral component of the system, receiving inputs, and initiating outputs.  Human factors were included in this standard from long ago...

The End

You can find a free pdf of the System Safety Engineering Standard, Mil-Std-882E, here.

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.
#Milstd882Technique #Milstd882Training #Milstd882tutorial #Milstd882Video #MilStd882E #Milstd882eTechnique #Milstd882eTraining #Milstd882etutorial #Milstd882eVideo #SafetystandardTechnique #SafetystandardTraining #Safetystandardtutorial #SafetystandardVideo #SHA #systemhazardanalysis #systemhazardanalysisTechnique #systemhazardanalysisTraining #systemhazardanalysistutorial #systemhazardanalysisVideo #SystemsafetyengineeringTechnique #systemsafetyengineeringtraining #Systemsafetyengineeringtutorial #SystemsafetyengineeringVideo #Task205
Simon Di Nucci https://www.safetyartisan.com/?p=480