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/

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/

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/

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/

Guidance on Safe Design

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



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



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



https://youtu.be/OuarJA9n8PQ

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



Get the video+ here



Topics: Safe Design



- A safe design approach;



- Five principles of safe design;



- Ergonomics and good work design;



- Responsibility for safe design;



- Product lifecycle;



- Benefits of safe design;



- Legal obligations; and



- Our national approach.



Transcript: Safe Design



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



Topics



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



Introduction



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



A Safe Design Approach #1



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



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



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



A Safe Design Approach #2



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



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



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



Five Principles of Safe Design



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



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



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



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



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



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



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



Questions? Leave a Comment

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

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

Safety Concepts Part 1

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



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



https://youtu.be/IKAZ3KLsDW8

System Safety Concepts - highlights.



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



Safety Concepts Part 1: Topics



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



- What is risk?



- What is risk reduction?



- What are safety requirements?



- Scope:



- What is the system?



- What is the application (function)?



- What is the (operating) environment?



Safety Concepts Part 1: Transcript



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



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



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



A Practical Definition of ‘Safe’



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



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



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



System Safety – Risk



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



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



System Safety – Requirements



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



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



Defining the Scope: The System



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



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



Defining the Scope: The Application



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



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



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



Defining the Scope: The Operating Environment



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



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



System Safety: why Bother?



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



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



Copyright



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



End: Safety Concepts Part 1



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



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



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



Meet the Author



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



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



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



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



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



•Presented on safety topics at several international conferences.

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

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