Wednesday, July 30, 2025



Home

The Safety Artisan gives you:



1. The flexibility that enables you to work and study2. Easy access to recorded classes to watch later3. Dynamic delivery based on practical experience



Learn safety engineering with me: a current industry professional with 25 years of experience.



Blog | Courses | Email



The Safety Artisan: Latest Articles



Free Lessons



How to Prepare for the CISSP Exam



System Safety Concepts & Principles



Risk Management 101



Safety Analysis Lessons



System Hazard Analysis (Mil-Std-882E) Course



System Requirements Hazard Analysis



Preliminary Hazard Identification



Software/Safety Lessons



Principles of Safe Software Course



Identify & Analyze Functional Hazards Course



System Safety Engineering Process



Testimonials



The way you teach this subject makes it comprehensible and part of an integral whole. It seems like your approach is rare (and valuable) in the world of System Safety.Thomas AnthonyDirector, Aviation Safety and Security ProgramViterbi School of EngineeringUniversity of Southern California



Understanding safety law can be difficult and, at times, confronting.  Thankfully, Simon has a knack of bringing clarity to complex legal requirements, using real work examples to help understanding.  I highly recommend Simon to any director or manager wanting to understand their legal obligations and ensure a safe workplace.Jonathan Carroll, Senior Leadership, Pacific National



Valuable information, Clear explanations, Engaging delivery, Helpful practice activities, Accurate course description, Knowledgeable instructor.Manuel Louie B. Santos, reviewing “Risk Management 101”



Explanation about the military standard was very interesting, because for the first time somebody talked about possible disadvantages.Henri Van Buren, reviewing “System Safety Risk Analysis Programs”



4,500+ Students on Udemy



200+ Reviews, scoring:



- Principles of Software Safety Standards (4.48 out of 5.00);



- How to Design a System Safety Program (4.08 out of 5.00);



- How to Prepare for the CISSP Exam (4.61 out of 5.00); and



- Risk Management 101 (4.39 out of 5.00).



Why Safety Engineering Training?



The world needs safety engineers - a lot of them. Everything we use needs to be designed, manufactured, supplied, transported, and so on, and we need to do that without causing harm.



So, there’s a lot of need for safety engineering training. Want a (well-paid) career as a safety engineer? Need to do a safety-engineering-related task or project?  Do you need to understand what your team is doing? Maybe you need to ask - or answer - the right questions in an interview.



There’s a lot of need for safety engineering skills, but they are difficult to get because training places are quite limited. Qualifications are expensive and take a long time to acquire.



I hope that by putting these lessons online, you’ll find them helpful. Who am I? Learn more.



It’s about Countering Fear – and Increasing Confidence



I decided to launch this site because I think there is a lot of fear around safety.  People worry about getting it wrong, and therefore sometimes that can result in poor behaviors or poor performance. They shy away from doing anything about safety rather than just doing what they can.



This is a shame because safety is often just structured common sense.



It’s an engineering discipline like any other. Except that we need to involve people other than engineers. We need to involve operators, maintainers, and regulators. We need to involve end-users. So it’s quite a social activity as well, which I’m afraid can be a challenge for some of us engineers!  (I’m as guilty of that as anybody else.) Nevertheless, there’s a lot we can do, and it isn’t as difficult as we think it is.



About the Author



learn more



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

Monday, July 28, 2025



Software Safety Principle 4

Software Safety Principle 4 is the third in a new series of six blog posts on Principles of Software Safety Assurance. In it, we look at the 4+1 principles that underlie all software safety standards. (The previous post in the series is here.)



We outline common software safety assurance principles that are evident in software safety standards and best practices. You can think of these guidelines as the unchanging foundation of any software safety argument because they hold across projects and domains.



The principles serve as a guide for cross-sector certification and aid in maintaining comprehension of the “big picture” of software safety issues while evaluating and negotiating the specifics of individual standards.



Principle 4: Hazardous Software Behaviour



The fourth software safety principle is:



Principle 4: Hazardous behaviour of the software shall be identified and mitigated.‘The Principles of Software Safety Assurance’, RD Hawkins, I Habli & TP Kelly, University of York.



Software safety requirements imposed on a software design can capture the high-level safety requirements' intent. However, this does not ensure that all of the software's potentially dangerous behaviors have been considered. Because of how the software has been created and built, there will frequently be unanticipated behaviors that cannot be understood through a straightforward requirements decomposition. These risky software behaviors could be caused by one of the following:



- Unintended interactions and behaviors brought on by software design choices; or



- Systematic mistakes made when developing software.



On 1 August 2005, a Boeing Company 777-200 aircraft, registered 9M-MRG, was being operated on a scheduled international passenger service from Perth to Kuala Lumpur, Malaysia. The crew experienced several frightening and contradictory cockpit indications.



This incident illustrates the issues that can result from unintended consequences of software design. Such incidents could only be foreseen through a methodical and detailed analysis of potential software failure mechanisms and their repercussions (both on the program and external systems). Putting safeguards in place to address potential harmful software behavior is possible if it has been found. However, doing so requires us to examine the potential impact of software design decisions.



Not all dangerous software behavior will develop as a result of unintended consequences of the software design. As a direct result of flaws made during the software design and implementation phases, dangerous behavior may also be seen. Seemingly minor development mistakes can have serious repercussions.



It's important to stress that this is not a problem with software quality in general. We exclusively focus on faults that potentially result in dangerous behavior for software safety assurance. As a result, efforts can be concentrated on lowering systematic errors in areas where they might have an impact on safety.



Since systematically establishing direct hazard causality for every error may not be possible in practice, it may be preferable for a while to accept what is regarded as best practice. However, the justification for doing so ought to at the very least be founded on knowledge from the software safety community on how the particular problem under consideration has led to safety-related accidents. 



To guarantee that adequate rigor is applied to their development, it is also crucial to identify the most crucial components of the software design. Any software behavior that may be risky must be recognized and stopped if there we are to be confident that the software will always behave safely.



Software Safety Principle 4: End of Part 3 (of 6)



This blog post is derived from ‘The Principles of Software Safety Assurance’, RD Hawkins, I Habli & TP Kelly, University of York. The original paper is available for free here. I was privileged to be taught safety engineering by Tim Kelly, and others, at the University of York. I am pleased to share their valuable work in a more accessible format.



Meet the Author



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!



Learn more about this subject in my course 'Principles of Safe Software' here. The next post in the series is here.

#issoftwaresafe #softwareengineeringriskanalysis #softwareengineeringriskmanagement #softwarehazardanalysisandresolutionindesign #softwarehazards #softwareimplementationrisks #softwareoperationalrisk #softwarequalityrisks #softwarerequirementsrisks #softwareriskcategories #softwareriskcategorization #softwareriskcharacteristics #softwareriskclassification #softwareriskcomponents #softwareriskdefinition #softwareriskexposure #softwareriskfactors #softwareriskidentification #softwareriskissues #softwareriskmanagementprocess #softwareriskmanagementprocessincludes #softwareriskmitigationrecommendations #softwarerisktypes #softwaresafetyexamples #softwaresafetyhazardanalysis #whatarecomputerhazards #whatarethehazardsofcomputer

Simon Di Nucci https://www.safetyartisan.com/2022/10/05/software-safety-principle-4/

Sunday, July 27, 2025



Blog Articles

Safety Engineering and Risk Management Blog Articles - The Safety Artisan



Start here with the Blog! The posts featured on this page introduce safety basics, such as definitions and fundamental safety concepts. They also discuss related topics.



You can also start here if you know how to do safety in one industry and want to understand how it's done in another. Similarly, you might be familiar with safety practices in one country but want to know how things are done elsewhere.



Latest Articles



Blog Articles: Selected Highlights



System Safety Concepts



The Safety Artisan equips you with System Safety Concepts. We look at the basic concepts of safety, risk and hazard in order to understand how to assess and manage them. Exploring these fundamental topics provides the foundations for all other safety topics, but it doesn't have to be complex. The basics are simple, but they need to be thoroughly understood and practised consistently to achieve success. This video explains the issues and discusses how to achieve that success.From the Lesson Description



What does 'Safe' really mean? Find out Here.



System Safety Principles



... I discuss the Principles of System Safety, as set out by the US Federal Aviation Authority in their System Safety Handbook.  Although this was published in 2000, the principles still hold good (mostly) and are worth discussing.  I comment on those topics where modern practice has moved on, and those jurisdictions where the US approach does not sit well.From the Lesson Description



Human Factors



In this 40-minute video, I'm joined by a friend, colleague and Human Factors specialist, Peter Benda. Peter has 23 years of experience in applying Human Factors to large projects in all kinds of domains. In this session we look at some fundamentals: what does Human Factors engineering aim to achieve? Why do it? And what sort of tools and techniques are useful? As this is The Safety Artisan, we also discuss some real-world examples of how Human Factors can contribute to accidents or help to prevent them.From the Lesson Description



Catch the discussion Here.



Functional Safety



Functional safety is the part of the overall safety of a system or piece of equipment that depends on automatic protection operating correctly in response to its inputs or failure in a predictable manner (fail-safe). The automatic protection system should be designed to properly handle likely human errors, systematic errors, hardware failures and operational/environmental stress.Wikipedia



For a brief introduction to Functional Safety Click Here.



Head back to the Topics Page for more safety training.



Simon Di Nucci https://www.safetyartisan.com/start-here-with-the-blog/

Thursday, July 24, 2025



System Safety Assessment

In this System Safety Assessment course, I will take you through a suite of safety analysis tasks. They are designed to deal with a complex system, but can be simplified (known as 'tailoring'). I start with Preliminary Hazard Identification and work through detailed analyses, each with a different point of view of the system.



Each lesson can be purchased individually, but there are discounts for the whole course here.



System Safety



The system safety concept calls for a risk management strategy based on identification, analysis of hazards and application of remedial controls using a systems-based approachHarold E. Roland; Brian Moriarty (1990). System Safety Engineering and Management.



System Safety Engineering



Every approach to safety has a context that needs to be understood to get the best results. I have used the Tasks from a system safety engineering standard called Military-Standard-882E, or Mil-Std-882E, for short. This has been around for a long time and is very widely used. It was developed for use on US military systems, but it has found its way, sometimes in disguise, into many other programs around the world.



However, any safety analysis standard can be applied blindly – it is not a substitute for competent decision-making. So, I explain the limitations with each Task and how to overcome them.



Safety Assessment



A safety assessment is a comprehensive and systematic investigation and analysis of all aspects of risks to health and safety associated with major incidents that may potentially occur in the course of operation of the major hazard facility...Guide for Major Hazard Facilities: Safety Assessment, Safe Work Australia, 2012



Safety Assessment



Head back to the Topics Page for more safety training.



Simon Di Nucci https://www.safetyartisan.com/safety-analysis/

Monday, July 21, 2025



Software Safety Principles 2 and 3

Software Safety Principles 2 and 3 is the second in a new series of blog posts on Principles of Software Safety Assurance. In it, we look at the 4+1 principles that underlie all software safety standards. (The previous blog post is here.)



We outline common software safety assurance principles that are evident in software safety standards and best practices. You can think of these guidelines as the unchanging foundation of any software safety argument because they hold true across projects and domains.



The principles serve as a guide for cross-sector certification and aid in maintaining comprehension of the “big picture” of software safety issues while evaluating and negotiating the specifics of individual standards.



Principle 2: Requirement Decomposition



The second software safety principle is:



Principle 2: The intent of the software safety requirements shall be maintained throughout requirements decomposition.‘The Principles of Software Safety Assurance’, RD Hawkins, I Habli & TP Kelly, University of York.



The requirements and design are gradually broken down as the software development lifecycle moves forwards, leading to the creation of a more intricate software design. The term "derived software requirements" refers to the criteria that were derived for the more intricate software design. The intent of those criteria must be upheld as the software safety requirements are broken down once they have been established as comprehensive and accurate at the highest (most abstract) level of design.



An example of the failure of requirements decomposition is the crash of Lufthansa Flight 2904 at Warsaw on 14 September 1993.



In essence, the issue is one of ongoing requirements validation. How do we show that the requirements expressed at one level of design abstraction are equal to those defined at a more abstract level? This difficulty arises constantly during the software development process.



It is insufficient to only consider requirements fulfillment. The software safety requirements had been met in the Flight 2904 example. However, they did not match the intent of the high-level safety requirements in the real world.



Human factors difficulties (a warning may be presented to a pilot as necessary, but that warning may not be noticed on the busy cockpit displays) are another consideration that may make the applicability of the decomposition more challenging.



Ensuring that all necessary details are included in the first high-level need is one possible theoretical solution to this issue. However, it would be difficult to accomplish this in real life. It is inevitable that design choices requiring more specific criteria will be made later in the software development lifecycle. It is not possible to accurately know this detail until that design choice has been made.



The decomposition of safety criteria must always be handled if the program is to be regarded as safe to use.



Requirements Satisfaction



The third software safety assurance principle is:



Principle 3: Software safety requirements shall be satisfied.‘The Principles of Software Safety Assurance’, RD Hawkins, I Habli & TP Kelly, University of York.



It must be confirmed that a set of "valid" software safety requirements has been met after they have been defined. This set may be assigned software safety requirements (Principle 1), or refined or derived software safety requirements (Principle 2). The fact that these standards are precise, well-defined, and actually verifiable is a crucial need for their satisfaction.



The sorts of verification techniques used to show that the software safety requirements have been met will vary on the degree of safety criticality, the stage of development, and the technology being employed. Therefore, attempting to specify certain verification methodologies that ought to be employed for the development of verification findings is neither practical nor wise.



Mars Polar Lander was an ambitious mission to set a spacecraft down near the edge of Mars' south polar cap and dig for water ice. The mission was lost on arrival on December 3, 1999.



Given the complexity and safety-critical nature of many software-based systems, it is obvious that using just one type of software verification is insufficient. As a result, a combination of verification techniques is frequently required to produce the verification evidence. Testing and expert review are frequently used to produce primary or secondary verification evidence. However, formal verification is increasingly emphasized because it may more reliably satisfy the software safety standards.



The main obstacle to proving that the software safety standards have been met is the evidence's inherent limitations as a result of the methods described above. The characteristics of the problem space are the root of the difficulties.



Given the complexity of software systems, especially those used to achieve autonomous capabilities, there are challenges with completeness for both testing and analysis methodologies. The underlying logic of the software can be verified using formal methods, but there are still significant drawbacks. Namely, it is difficult to provide assurance of model validity. Also, formal methods do not deal with the crucial problem of hardware integration.



Clearly, the capacity to meet the stated software safety requirements is a prerequisite for ensuring the safety of software systems.



Software Safety Principles 2 & 3: End of Part 2 (of 6)



This blog post is derived from ‘The Principles of Software Safety Assurance’, RD Hawkins, I Habli & TP Kelly, University of York. The original paper is available for free here. I was privileged to be taught safety engineering by Tim Kelly, and others, at the University of York. I am pleased to share their valuable work in a more accessible format.



Meet the Author



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!



Learn more about this subject in my course 'Principles of Safe Software' here. The next post in the series is here.

#decomposedrequirements #decompositionofrequirements #howtowritesoftwaresafetyrequirements #requirementdecomposition #requirementssatisfaction #satisfiestherequirements #satisfyrequirement #softwaresafetycertification #softwaresafetyplan #softwaresafetyrequirement #softwaresafetyrequirements #softwaresafetyrequirementsexample #softwaresafetyrequirementsspecification #softwaresafetystandard #softwaresafetystandards #softwaresafetytesting #softwaresystemsafety

Simon Di Nucci https://www.safetyartisan.com/2022/09/28/software-safety-principles-2-and-3/


Introduction to WHS Codes of Practice

In the 30-minute session, we introduce Australian WHS Codes of Practice (CoP). We cover: What they are and how to use them; their Limitations; we List (Federal) codes; provide Further commentary; and Where to get more information. This session is a useful prerequisite to all the other sessions on CoP.



https://youtu.be/JAOeNfPaULU



Codes of Practice: Topics



- What they are and how to use them;

- Limitations;

- List of CoP (Federal);

- Further commentary; and

- Where to get more information.



Codes of Practice: Transcript



Click Here for the Transcript

Hello and welcome to the Safety Artisan, where you will find professional, pragmatic, and impartial teaching and resources on all thing’s safety. I'm Simon and today is the 16th of August 2020. Welcome to the show.



Introduction



So, today we're going to be talking about Codes of Practice. In fact, we're going to be introducing Codes of Practice and the whole concept of what they are and what they do.



Topics for this Session



What we're going to cover is what Codes of Practice are and how to use them – several slides on that; a brief word on their limitations; a list of federal codes of practice – and I'll explain why I'm emphasizing it's the list of federal ones; some further commentary and where to get more information. So, all useful stuff I hope.



CoP are Guidance...



So, Codes of Practice come in the work, health and safety hierarchy below the act and regulations. So, at the top you've got the WHS Act, then you've got the WTS regulations, which the act calls up. And then you've got the Codes of Practice, which also the act calls up. We'll see that in a moment. And what Codes of Practice do are they provide practical guidance on how to achieve the standards of work, health and safety required under the WHS act and regulations, and some effective ways to identify and manage risks. So, they’re guidance but as we'll see in a moment, they're much more than guidance. So, as I said, the Codes of Practice are called up by the act and they're approved and signed off by the relevant minister. So, they are a legislative instrument.



Now, a quick footnote. These words, by the way, are in the introduction to every Code of Practice. There's a little note here that says we're required to consider all risks associated with work, not just for those risks that have associated codes of practice. So, we can't hide behind that. We've got to think about everything. There are codes of practice for several things, but not everything. Not by a long way.



...Guidance We Should Follow



Now, there are three reasons why Codes of Practice are a bit more than just guidance. So, first of all, they are admissible in court proceedings. Secondly, they are evidence of what is known about a hazard, risk, risk assessment, risk control. And thirdly, courts may rely, or regulators may rely, on Codes of Practice to determine what is reasonably practicable in the circumstances to which the code applies. So, what's the significance of that?



So first of all, the issue about being admissible. If you're unfortunate enough to go to court and be accused of failing under WHS law, then you will be able to appeal to a Code of Practice in your defence and say, “I complied with the Code of Practice”. They are admissible in court proceedings. However, beyond that, all bets are off. It's the court that decides what is anadmissible defence, and that means lawyers decide, not engineers. Now, given that you're in court and the incident has already happened a lot of the engineering stuff that we do about predicting the probability of things is no longer relevant. The accident has happened. Somebody has got hurt. All these probability arguments are dust in your in the wake of the accident. So, Codes of Practice are a reliable defence.



Secondly, the bit about evidence of what is known is significant, because when we're talking about what is reasonably practicable, the definition of reasonably practicable in Section 18 of the WHS act talks about what it is reasonable or what should have been known when people were anticipating the risk and managing it. Now, given that Codes of Practice were published back in 2012, there's no excuse for not having read them. So, they’re pre –existing, they're clearly relevant, the law has said that they're admissible in court. We should have read them, and we should have acted upon them. And there'll be no wriggling out of that. So, if we haven't done something that CoP guided us to do, we're going to look very vulnerable in court.  Or in the whatever court of judgment we're up against, whether it be public opinion or trial by media or whatever it is.



And thirdly, some CoP can be used to help determine what is SOFARP. So in some circumstances, if you're dealing with a risk that's described a CoP, CoP is applicable. Then if you followed everything in CoP, then you might be able to claim that just doing that means that you've managed the risk SFARP. Why is that important? Because the only way we are legally allowed to expose people to risk is if we have eliminated or minimized that risk so far as is reasonably practicable, SFARP. That is the key test, the acid test, of “Have we met our risk management obligations? “And CoP are useful, maybe crucial, in two different ways for determining what is SFARP. So yes, they’re guidance but it's guidance that we ignore at our peril.



Standards & Good Practice



So, moving on. Codes of Practice recognize, and I reemphasize this is in the introduction to every code of practice, they're not the only way of doing things. There isn't a CoP for everything under the sun. So, codes recognize that you can achieve compliance with WHS obligations by using another method as long as it provides an equivalent or higher standard of work, health and safety than the code. It's important to recognize that Codes of Practice are basic. They apply to every business and undertaking in Australia potentially. So, if you're doing something more sophisticated, then probably CoP on their own are not enough. They're not good enough.



And in my day job as a consultant, that's the kind of stuff we do. We do planes, trains and automobiles. We do ships and submarines. We do nuclear. We do infrastructure. We do all kinds of complex stuff for which there are standards and recognized good practice which go way beyond the requirements of basic Codes of Practice. And many I would say, probably most, technical and industry safety standards and practices are more demanding than Codes of Practice. So, if you're following an industry or technical standard that says “Here's a risk management process”, then it's likely that that will be far more detailed than the requirements that are in Codes of Practice.



And just a little note to say that for those of us who love numbers and quantitative safety analysis, what this statement about equivalent or higher standards of health and safety is talking about  –We want requirements that are more demanding and more rigorous or more detailed than CoP. Not that the end –result in the predicted probability of something happening is better than what you would get with CoP because nobody knows what you would get with CoP. That calculation hasn't been done. So, don't go down the rabbit hole of thinking “I've got a quantitatively demonstrate that what we're doing is better than CoP.” You haven't. It's all about demonstrating the input requirements are more demanding rather than the output because that's never been done for CoP. So, you've got no benchmark to measure against in output terms.



The primacy of WHS & Regulations



A quick point to note that Codes of Practice, they are only guidance. They do refer to relevant WHS act and regulations, the hard obligations, and we should not be relying solely on codes in place of what it says in the WHS Act or the regulations. So, we need to remember that codes are not a substitute for the act or the regs. Rather they are a useful introduction. WHS ACT and regulations are actually surprisingly clear and easy to read. But even so, there are 600 regulations. There are hundreds of sections of the WHS act. It's a big read and not all of it is going to be relevant to every business, by a long way. So, if you see a CoP that clearly applies to something that you're doing, start with the cop. It will lead you into the relevant parts of WHS act and regulations. If you don't know them, have a read around in there around the stuff that – you've been given the pointer in the CoP, follow it up.



But also, CoP do represent a minimum level of knowledge that you should have. Again, start with CoP, don't stop with them. So, go on a bit. Look at the authoritative information in the act and the regs and then see if there's anything else that you need to do or need to consider. The CoP will get you started.



And then finally, it's a reference for determining SOFARP. You won't see anything other than the definition of reasonably practicable in the Act. You won't see any practical guidance in the Act or the regulations on how to achieve SOFARP. Whereas CoP does give you a narrative that you can follow and understand and maybe even paraphrase if you need to in some safety documentation. So, they are useful for that. There’s also guidance on reasonably practicable, but we'll come to that at the end.



Detailed Requirements



It's worth mentioning that there are some detailed requirements in codes. Now, when I did this, I think I was looking at the risk management Code of Practice, which will go through later in another session. But in this example, there are this many requirements. So, every CoP has the statement “The words ‘must’, ‘requires’, or ‘mandatory’ indicate a legal requirement exists that must be complied with.” So, if you see ‘must’, ‘requires’, or ‘mandatory’, you've got to do it. And in this example CoP that I was looking at, there are 35 ‘must’s, 39 ‘required’ or ‘requirement’ – that kind of wording – and three instances of ‘mandatory’. Now, bearing in mind the sentence that introduces those things contains two instances of ‘must’ and one of ‘requires’ and one of ‘mandatory’. So, straight away you can ignore those four instances. But clearly, there are lots of instances here of ‘must’ and ‘require’ and a couple of ‘mandatory’.



Then we've got the word ‘should’ is used in this code to indicate a recommended course of action, while ‘may’ is used to indicate an optional course of action. So, the way I would suggest interpreting that and this is just my personal opinion – I have never seen any good guidance on this. If it says ‘recommended’, then personally I would do it unless I can justify there's a good reason for not doing it. And if it said ‘optional’, then I would consider it. But I might discard it if I felt it wasn't helpful or I felt there was a better way to do it. So, that would be my personal interpretation of how to approach those words. So, ‘recommended’ – do it unless you can justify not doing it. ‘Optional’ – Consider it, but you don't have to do it.



And in this particular one, we've got 43 instances of ‘should’ and 82 of ‘may’. So, there's a lot of detailed information in each CoP in order to consider. So, read them carefully and comply with them where you have to work and that will repay you. So, a positive way to look at it, CoP are there to help you. They're there to make life easy for you. Read them, follow them. The negative way to look at them is, ”I don't need to do all this says in CoP because it's only guidance”. You can have that attitude if you want. If you're in the dock or in the witness box in court, that's not going to be a good look. Let's move on.



Limitations of CoP



So, I've talked CoP up quite a lot; as you can tell, I'm a fan because I like anything that helps us do the job, but they do have limitations. I've said before that there's a limited number of them and they're pretty basic. First of all, it's worth noting that there are two really generic Codes of Practice. First of all, there's the one on risk management. And then secondly, there's the one on communication, consultation and cooperation. And I'll be doing sessions on both of those. Now, those apply to pretty much everything we do in the safety world. So, it's essential that you read them no matter what you're doing and comply with them where you have to.



Then there are other codes of practice that apply to specific activities or hazards, and some of them are very, very specific, like getting rid of asbestos, or welding, or spray painting – or whatever it might be – shock blasting. Those have clearly got a very narrow focus. So, you will know if you're doing that stuff. So, if you are doing welding and clearly you need to read the welding CoP. If welding isn't part of your business or undertaking, you can forget it.



However, overall, there are less than 25 Codes of Practice. I can't be more precise for reasons that we will come to in a moment. So, there's a relatively small number of CoP and they don't cover complex things. They're not going to help you design a super –duper widget or some software or anything like that. It's not going to help you do anything complicated. Also, Codes of Practice tend to focus on the workplace, which is understandable. They're not much help when it comes to design trade –offs. They're great for the sort of foundational stuff. Yes, we have to do all of this stuff regardless. When you get to questions of, “How much is enough?” Sometimes in safety, we say, “How much margin do I need?” “How many layers of protection do I need?” “Have I done enough?” CoP aren't going to be a lot of use helping you with that kind of determination but you do need to have made sure you've done everything CoP first and then start thinking about those trade –offs, would be my advice. You're less likely to go wrong that way. So, start with your firm basis of what you have to do to comply and then think “What else could I do?”



List of CoP (Federal) #1



Now for information, you’ve got three slides here where we've got a list of the Codes of Practice that apply at the federal or Commonwealth level of government in Australia. So, at the top highlighted I've already mentioned the ‘how’ to manage WHS risks and the consultation, cooperation, and coordination codes. Then we get into stuff like abrasive, blasting, confined spaces, construction and demolition and excavation, first aid. So, quite a range of stuff, covered.



List of CoP (Federal) #2



Hazardous manual tasks – so basically human beings carrying and moving stuff. Managing and controlling asbestos, and removing it. Then we've got a couple on hazardous chemicals on this page, electrical risks, managing noise, preventing hearing loss, and stevedoring. There you go. So, if you're into stevedoring, then this CoP is for you. The highlighted ones we're going to cover in later sessions.



List of CoP (Federal) #3



Then we've got managing risk of Plant in the workplace. There was going to be a Code of Practice for the design of Plant, but that never saw the light of day so we've only got guidance on that. We've got falls, environment, work environment, and facilities. We've got another one on safety data sheets for another one on hazardous chemicals, preventing falls in housing – I guess because that's very common accident – safe design of structures, spray painting and powder coating, and welding processes. So, those are the list of – I think it's 24 – Codes of Practice are applied by Comcare, the federal regulator.



Commentary #1



Now, I'm being explicit about which regulator and which set of CoP, because they vary around Australia. Basically, the background was the model Codes of Practice were developed by Safe Work Australia, which is a national body. But those model Codes of Practice do not apply. Safe Work Australia is not a regulator. Codes of Practice are implemented or enforced by the federal government and by most states and territories. And it says with variations for a reason. Not all states and territories impose all codes of practice. For example, I live in South Australia and if you go and look at the WorkSafe South Australia website or Safe Work – whatever it's called – you will see that there's a couple of CoP that for some reason we don't enforce in South Australia. Why? I do not know. But you do need to think about these things depending on where you're operating.



It's also worth saying that WHS is not implemented in every state in Australia. Western Australia currently have plans to implement WHS, but as of 2020 but I don't believe they've done so yet. Hopefully, it's coming soon. And Victoria, for some unknown reason, have decided they're just not going to play ball with everybody else. They've got no plans to implement WHS that I can find online. They're still using their old OHS legislation. It's not a universal picture in Australia, thanks to our rather silly version of government that we have here in Australia – forget I said that. So, if it's a Commonwealth workplace and we apply the federal version of WHS and Codes of Practice. Otherwise, we use state or territory versions and you need to see the local regulator's Web page to find out what is applied where. And the definition of a Commonwealth workplace is in the WHS Act, but also go and have a look at the Comcare website to see who Comcare police. Because there are some nationalised industries that count as a Commonwealth workplace and it can get a bit messy.



So, sometimes you may have to ask for advice from the regulator but go and see what they say. Don't rely on what consultants say or what you've heard on the grapevine. Go and see what the regulator actually says and make sure it's the right regulator for where you're operating.



Commentary #2



What’s to come? I'm going to do a session on the Risk Management Code of Practice, and I'm also, associated with that, going to do a session on the guidance on what is reasonably practicable. Now that's guidance, it’s not a Code of Practice. But again, it's been published so we need to be aware of it and it's also very simple and very helpful. I would strongly recommend looking at that guidance if you're struggling with SFARP for what it means, it's very good. I'll be talking about that soon. Also, I'm going to do a session on tolerability of risk, because you remember when I said “CoP aren't much good for helping you do trade–offs in design” and that kind of thing. They're really only good for simple stuff and compliance. Well, what you need to understand to deal with the more sophisticated problems is the concept of tolerability of risk. That’ll help us do those things. So, I'm going to do a session on that.



I'm also going to do a session on consultation, cooperation, and coordination, because, as I said before, that's universally applicable. If we're doing anything at a workplace, or with stuff that's going to a workplace, that we need to be aware of what's in that code. And then I'm also going to do sessions on plant, structures and substances (or hazardous chemicals) because those are the absolute bread and butter of the WHS Act. If you look at the duties of designers, manufacturers, importers, suppliers, and installers, et cetera, you will find requirements on plant, substances and structures all the way through those clauses in the WHS Act. Those three things are key so we're going to be talking about that.



Now, I mentioned before that there was going to be a Code of Practice on plant design, but it never made it. It's just guidance. So, we'll have a look at that if we can as well – Copyright permitting. And then I want to look at electrical risks because I think the electrical risks code is very useful.

#coursesafetyengineering #engineersafety #ineedsafety #Introduction #knowledgeofsafety #learnsafety #needforsafety #riskanalysis #riskassessment #riskmanagement #safetyblog #safetydo #safetyengineer #safetyengineerskills #safetyengineertraining #safetyengineeringcourse #safetyprinciples #safetytraining #softwaresafety #theneedforsafety #WHSAct #WHSCodeofPractice #WHSRegulations

Simon Di Nucci https://www.safetyartisan.com/2020/09/13/introduction-to-whs-codes-of-practice/

Friday, July 18, 2025



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/

Tuesday, July 15, 2025



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/

Monday, July 14, 2025



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/

Monday, July 7, 2025



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/

Saturday, July 5, 2025



Sub-System Hazard Analysis with Mil-Std-882E
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

Safe Design in Australia: Overview, Statistics, and Principles This post provides an overview of Safe Design in Australia: Overview, Statis...