Functional Hazard Analysis with Mil-Std-882E
In this video, I look at Functional Hazard Analysis with Mil-Std-882E (FHA, which is Task 208 in Mil-Std-882E). FHA analyses software, complex electronic hardware, and human interactions. I explore the aim, description, and contracting requirements of this Task, and provide extensive commentary on it. (I refer to other lessons for special techniques for software safety and Human Factors.)

This video, and the related webinar 'Identify & Analyze Functional Hazards', deal with an important topic. Programmable electronics and software now run so much of our modern world. They control many safety-related products and services. If they go wrong, they can hurt people.

I've been working with software-intensive systems since 1994. Functional hazards are often misunderstood or overlooked, as they are hidden. However, the accidents that they can cause are very real. If you want to expand your analysis skills beyond just physical hazards, I will show you how.

https://youtu.be/f4jDnnqYhus
This is the seven-minute demo; the full version is 40 minutes long.

clikc here to get the course: Identify & analyze functional hazards

Functional Hazard Analysis: Context

So how do we analyze software safety?

Before we even start, we need to identify those system functions that may impact safety. We can do this by performing a Functional Failure Analysis (FFA) of all system requirements that might credibly lead to human harm.

An FFA looks at functional requirements (the system should do 'this' or 'that') and examines what could go wrong:

- Does the function work when needed?

- Does the function work when not required?

- Does the function work incorrectly? (There may be more than one version of this.)

(A variation of this technique is explained here.)

If the function could lead to a hazard then it is marked for further analysis. This is where we apply the FHA, Task 208.

Functional Hazard Analysis: The Lesson

Topics: Functional Hazard Analysis

- Task 208 Purpose;

- Task Description;

- Update & Reporting

- Contracting; and

- Commentary.

Transcript: Functional Hazard Analysis

Introduction

Hello, everyone, and welcome to the Safety Artisan; Home of Safety Engineering Training. I'm Simon and today we're going to be looking at how you analyze the safety of functions of complex hardware and software. We'll see what that's all about in just a second.

Functional Hazard Analysis

I'm just going to get to the right page. This, as you can see, functional hazard analysis is Task 208 in Mil. Standard 882E.

Topics for this Session

What we've got for today: we have three slides on the purpose of functional hazard analysis, and these are all taken from the standard. We've got six slides of task description. That's the text from the standard plus we've got two tables that show you how it's done from another part of the standard, not from Task 208. Then we've got update and recording, another two slides. Contracting, two slides. And five slides of commentary, which again include a couple of tables to illustrate what we're talking about.

Functional Purpose HA #1

What we're going to talk about is, as I say, functional hazard analysis. So, first of all, what's the purpose of it? In classic 882 style, Task 208 is to perform this functional hazard analysis on a system or subsystem or more than one. Again, as with all the other tasks, we use it to identify and classify system functions and the safety consequences of functional failure or malfunction. In other words, hazards.

Now, I should point out at this stage that the standard is focused on malfunctions of the system. In the real world, lots of software-intensive systems cause accidents that have killed people, even when they're functioning as intended. That's one of the shortcomings of this Military Standard - it focuses on failure. But even if something performs as specified, either:

- The specification might be wrong, or

- The system might do something that the human operator does not expects.

Mil-Std-882E just doesn't recognize that. So, it's not very good in that respect. However, bearing that in mind, let's carry on with looking at the task.

Functional HA Purpose #2

We're going to look at these consequences in terms of severity – severity only, we'll come back to that – to identify what they call safety-critical functions, safety-critical items, safety-related functions, and safety-related items. And a quick word on that, I hate the term ‘safety-critical’ because it suggests a sort of binary “Either it's safety-critical. Yes. Or it's not safety-critical. No.” And lots of people take that to mean if it's “safety-critical, no,” then it's got nothing to do with safety. They don't recognize that there's a sliding scale between maximum safety criticality and none whatsoever. And that's led to a lot of bad thinking and bad behavior over the years where people do everything they can to pretend that something isn't safety-related by saying, “Oh, it's not safety-critical, therefore we don't have to do anything.” And that kind of laziness kills people.

Anyway, moving on. So, we've got these SCFs, SCIs, SRFs, SRIs and they're supposed to be allocated or mapped to a system design architecture. The presumption in this – the assumption in this task is that we're doing early – We'll see that later – and that system design, system architecture, is still up for grabs. We can still influence it.

COTS and MOTS Software

Often that is not the case these days. This standard was written many years ago when the military used to buy loads of bespoke equipment and have it all developed from new. That doesn't happen anymore so much in the military and it certainly doesn't happen in many other walks of life – But we'll talk about how you deal with the realities later.

And they're allocating these functions and these items of interest to hardware, software, and human interfaces. And I should point out, when we're talking about all that, all these things are complex. Software is complex, human is complex, and we're talking about complex hardware. So, we're talking about components where you can't just say, “Oh, it's got a reliability of X, and that's how often it goes wrong” because those types of simple components are only really subject to random failure, that's not what we're talking about here.

We're talking about complex stuff where we're talking about systematic failure dominating over random, simple hardware failure. So, that's the focus of this task and what we're talking about. That's not explained in the standard, but that's what's going on.

Functional HA Purpose #3

Now, our third slide is on purpose; so, we use the FHA to identify the consequences of malfunction, functional failure, or lack of function. As I said just now, we need to do this as early as possible in the systems engineering process to enable us to influence the design. Of course, this is assuming that there is a system engineering process – that's not always the case. We'll talk about that at the end as well.

Also, we're going to identify and document these functions and items and allocate and it says to partition them in the software design architecture. When we say partition, that's jargon for separating them into independent functions. We'll see the value of that later on. Then we're going to identify requirements and constraints to put on the design team to say, “To achieve this allocation in this partitioning, this is what you must do and this is what you must not do”. So again, the assumption is we're doing this early. There's a significant amount of bespoke design yet to be done....

Then What?

Once the FFA has identified the required 'Level or Rigor', we need to translate that into a suitable software development standard. This might be:

- RTCA DO-178C (also know as ED-12C) for civil aviation;

- The US Joint Software System Safety Engineering Handbook (JSSEH) for military systems;

- IEC 61508 (functional safety) for the process industry;

- CENELEC-50128 for the rail industry; and

- ISO 26262 for automotive applications.

Such standards use Safety Integrity Levels (SILs) or Development Assurance Levels (DALs) to enforce appropriate Levels of Rigor. You can learn about those in my course, Principles of Safe Software Development.

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!
#functionalhazard #functionalhazardindigitalelectronics #functionalriskassessment #functionalriskexample #functionalsafety #functionalsafetyanalysis #functionalsafetycourse #functionalsafetyonlinecourse #functionalsafetyppt #functionalsafetyrequirements #functionalsafetystandards #functionalsafetytechniquelearnfunctionalsafety #functionalsafetytraining #functionalsafetytrainingAustralia #functionalsafetytutorial #functionalsafetyvideo #hazardfunctiondefinition #howtodofunctionalsafety #Milstd882Technique #Milstd882Training #Milstd882tutorial #Milstd882Video #MilStd882E #whatisfunctionalrisk
Simon Di Nucci https://www.safetyartisan.com/2024/03/20/functional-hazard-analysis-task-208/

My CISSP Exam Journey
Here is a video about my CISSP exam journey.

https://youtu.be/zGof2cB9VW8
I've just passed the Certified Information Systems Security Professional (CISSP) Exam...

Get the full 'My CISSP Exam Journey' free video here.

I've just passed the Certified Information Systems Security Professional (CISSP) Exam, which was significantly updated on 1st May 2021. In this 30-minute video, I will cover:

- The official CISSP course and course guide;

- The 8 Domains of CISSP, and how to take stock of your knowledge of them;

- The official practice questions and the Study Guide;

- The CISSP Exam itself; and

- Lessons learned from my journey.

I wish you every success in your CISSP journey: it's tough, but you can do it!

Transcript: My CISSP Exam Journey

Hi, Everyone,

My name is Simon Di Nucci and I've just passed the new CISSP exam; for those of you who don't know what that is, that's the Certified Information Systems Security professional. It's new because the exams have been around a long time, but the syllabus and the exam itself have undergone a significant change as of the 1st of May this year. I’m probably one of the first people to pass the new exam, which I have to tell you was a great relief because it was really it was a tough exam and it was tough preparing for it.

It was a big mountain to climb. I am very, very relieved to have passed. Now, I hope to share some lessons with you. When I mentioned that I passed on the cybersecurity groups on Facebook and LinkedIn, I got a huge response from people who appreciated how difficult it is to do this and also lots of questions. And whilst I can't talk about the specifics of the exam, that's not allowed, I can share some really useful lessons learned from my journey.

Introduction

So I'm going to be talking about what I did:

- The Official Course, and the Student Guide;

- How I took stock at the start of the revision process;

- How I revised using the practice questions and the Study Guide;

- Something about the exam itself; and

- Lessons learned.

The Official Course

So let's get on with it.  My journey was that two or three years ago, the firm that I worked for decided that they wanted me to take the CISSP exam in order to improve our credibility when doing cybersecurity, and my credibility.

I was sent on a five-day course, which was very intense, and it was the official book.is the official ISC2 course. And that was several hundred slides a day for five days. It was very intense. And as you can see, the guy that you get with a pretty hefty eight hundred pages of closely packed and high-quality material. I was taught by someone who was clearly a very experienced expert in the field.

It was a good quality course. It cost about $3,700 (Australian). I think that's about $2,500 (US). In terms of the investment, I think it was worth it because it covered a lot of ground, and I was very rusty on a lot of this stuff. It was it was a useful ‘crammer’ to get back into this stuff. As I said, 800 pages long. I've done a lot of revising!

Practical Things

Let's put that to one side. The course was very good, but of course, it takes some time out of your schedule to do it. You need the money and the support from your workplace to be able to do that. There are now online courses, which I haven't been on; I can't say how good they are, but they are cheaper, and they're spread out. I think you do a day or two per week for a period of several weeks.

And I think that's got to be really good because you're going to have more time to consolidate this huge amount of information in your head. No disrespect to the face-to-face course. It was very good. I think the online courses could be even better and a lot more accessible.  That was the course. Now, I did that in November twenty nineteen and I intended to do some revision and then take the exam probably in early.

In March, April 2020, global events got in the way of that, and all the exam centers were closed down. I couldn't do that. Basically, I sort of forgot about it for a period of months. And then at the tail end of 2020, as things began to improve here in Australia at least, we've been very lucky here, exam centers reopened, and I thought, well, I really should get back and, you know, try and schedule the exam and do some revision and get on with it.

Exam Preparation

So I did. And starting in January of this year, I got my management agreement that I would spend one day a week working from home, revising, and that's what I did. Given that I took the exam in the middle of May, that's probably 18 full days of revision going through the material, and I needed it! Originally, I was going to take the exam, I think, in early April, but I realized at the end of March that I was not ready and I needed more time.

So I put the exam date back to the middle of May. And it was only after I'd done that that it was announced that the syllabus of the exam was changing quite significantly. That was a, you know, extra work then. And fortunately. They. They brought out the official guide to the new exam, and I realized that quite a lot of material to learn. I went through, and for example, there are eight domains in CISSP.

And for example, here's domain number two, asset security. In the pink, I have highlighted all the new things that are in the 1st of May Edition syllabus that were not in the 2018 syllabus.  I went through all of these things, and there are quite a few in almost every domain except the first one. There are significant changes.  I had to do a lot of extra revision because the syllabus had changed, but nevertheless, it was doable.

To get regular updates from The Safety Artisan, Click Here. For more introductory lessons Start Here.
#CISSP #CISSP2021 #CISSP2021Exam #cisspisanexampleofasecuritycertification #cisspobjectives #cissppearson #cisspqualification #cisspwhatisit #coursesafetyengineering #Cybersecurity #engineersafety #ineedsafety #knowledgeofsafety #learnsafety #needforsafety #safetyblog #safetydo #safetyengineer #safetyengineerskills #safetyengineertraining #safetyengineeringcourse #safetyprinciples #softwaresafety #theneedforsafety
Simon Di Nucci https://www.safetyartisan.com/2023/09/27/my-cissp-exam-journey/

Software Safety Principles Conclusions and References
Software Safety Principles Conclusions and References is the sixth and final blog post on Principles of Software Safety Assurance. In them, we look at the 4+1 principles that underlie all software safety standards. (The previous post in the series is here.)

Read on to Benefit From...

The conclusions of this paper are brief and readable, but very valuable. It's important for us - as professionals and team players - to be able to express these things to managers and other stakeholders clearly. Talking to non-specialists is something that most technical people could do better.

The references include links to the standards covered by the paper. Unsurprisingly, these are some of the most popular and widely used processes in software engineering. The other links take us to the key case studies that support the conclusions.

Content

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.

Conclusion

These six blog posts have presented the 4+1 model of foundational principles of software safety assurance. The principles strongly connect to elements of current software safety assurance standards and they act as a common benchmark against which standards can be measured.

Through the examples provided, it's also clear that, although these concepts can be stated clearly, they haven't always been put into practice. There may still be difficulties with their application by current standards. Particularly, there is still a great deal of research and discussion going on about the management of confidence with respect to software safety assurance (Principle 4+1).

Standards and References

RTCA/EUROCAE, Software Considerations in Airborne Systems and Equipment Certification, DO-178C/ED-12C, 2011.

CENELEC, EN-50128:2011 - Railway applications - Communication, signaling and processing systems - Software for railway control and protection systems, 2011.

ISO-26262 Road vehicles – Functional safety, FDIS, International Organization for Standardization (ISO), 2011

IEC-61508 – Functional Safety of Electrical / Electronic / Programmable Electronic Safety-Related Systems. International Electrotechnical Commission (IEC), 1998

FDA, Examples of Reported Infusion Pump Problems, Accessed on 27 September 2012,

http://www.fda.gov/MedicalDevices/ProductsandMedicalProcedures/GeneralHospitalDevicesandSupplies/InfusionPumps/ucm202496.htm

FDA, FDA Issues Statement on Baxter’s Recall of Colleague Infusion Pumps, Accessed on 27 September 2012, http://www.fda.gov/NewsEvents/Newsroom/PressAnnouncements/ucm210664.htm

FDA, Total Product Life Cycle: Infusion Pump - Premarket Notification 510(k) Submissions, Draft Guidance, April 23, 2010.

“Report on the Accident to Airbus A320-211 Aircraft in Warsaw on 14 September 1993”, Main Commission Aircraft Accident Investigation Warsaw, March 1994, http://www.rvs.unibielefeld.de/publications/Incidents/DOCS/ComAndRep/Warsaw/warsaw-report.html  Accessed on 1st October 2012.

JPL Special Review Board, "Report on the Loss of the Mars Polar Lander and Deep Space 2 Missions", Jet Propulsion Laboratory”, March 2000.

Australian Transport Safety Bureau. In-Flight Upset Event 240Km North-West of Perth, WA, Boeing Company 777-2000, 9M-MRG. Aviation Occurrence Report 200503722, 2007.

H. Wolpe, General Accounting Office Report on Patriot Missile Software Problem, February 4, 1992, Accessed on 1st October 2012, Available at: http://www.fas.org/spp/starwars/gao/im92026.htm

Y.C. Yeh, Triple-Triple Redundant 777 Primary Flight Computer, IEEE Aerospace Applications Conference pg 293-307, 1996.

D.M. Hunns and N. Wainwright, Software-based protection for Sizewell B: the regulator’s perspective. Nuclear Engineering International, September 1991.

R.D. Hawkins, T.P. Kelly, A Framework for Determining the Sufficiency of Software Safety Assurance. IET System Safety Conference, 2012.

SAE. ARP 4754 - Guidelines for Development of Civil Aircraft and Systems. 1996.

Software Safety Principles: End of the Series

This blog post series was derived from ‘The Principles of Software Safety Assurance’, by 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!

Principles of Software Safety Training

Learn more about this subject in my course 'Principles of Safe Software' here.

My course on Udemy, 'Principles of Software Safety Standards' is a cut-down version of the full Principles Course. Nevertheless, it still scores 4.42 out of 5.00 and attracts comments like:

- "It gives me an idea of standards as to how they are developed and the downward pyramid model of it." 4* Niveditha V.

- "This was really good course for starting the software safety standareds, comparing and reviewing strengths and weakness of them. Loved the how he try to fit each standared with4+1 principles. Highly recommend to anyone that want get into software safety." 4.5* Amila R.

- "The information provides a good overview. Perfect for someone like me who has worked with the standards but did not necessarily understand how the framework works." 5* Mahesh Koonath V.

- "Really good overview of key software standards and their strengths and weaknesses against the 4+1 Safety Principles." 4.5* Ann H.
#basicprinciplesofsafety #issafetyimportant #principlesforsoftwaredesign #principlesofsoftwareengineering #principlesofsoftwarevalidation #safeprinciplesexplained #safesystemprinciples #safetyassessmentprinciples #safetyprinciples #safetyprinciplesandpractices #softwareanalysisprinciples #softwaredesignprinciplesexamples #softwaredevelopmentprinciple #softwaredevelopmentprinciplesandpractices #softwareengineeringprinciplesarebasedon #softwareengineeringprinciplesppt #softwareprinciples #softwareprinciplesinsoftwareengineering #softwarequalityprinciples #softwaresafetycertification #softwaresafetydefinition #softwaresafetyengineering #softwaresafetyexamples #softwaresafetyprinciples #softwaresafetyrequirements #softwaresafetyrequirementsexample #softwaresafetystandards #softwaresafetytesting #softwaresystemsafety #whataresoftwaredesignprinciples
Simon Di Nucci https://www.safetyartisan.com/2022/11/23/sw-safety-principles-conclusions-and-references/

Australian WHS Course
In this Australian WHS Course, we show you how to practically and pragmatically implement the essential elements of Australian Work Health and Safety Legislation. In particular, we look at the so-called 'upstream' WHS duties. These are the elements you need to safely introduce systems and services into the Australian market.

Lessons in This Course

A Guide to the Australian WHS Act

Image by Wendy Van Zyl, from Pexels

This Guide to the WHS Act covers many topics of interest to system safety and design safety specialists, this full-length video covers key sections (§) of the Act:

- § 3, Object ;

- § 4-8, Definitions;

- § 12A, Exclusions;

- § 18, Reasonably Practicable;

- § 19, Primary Duty of Care;

- § 22-26, Duties of Designers, Manufacturers, Importers, Suppliers & those who Install/Construct/Commission;

- § 27, Officers & Due Diligence;

- § 46-49, Consult, Cooperate & Coordinate;

- § 152, Function of the Regulator; and

- § 274-276, WHS Regulations and CoP.

The Consultation, Cooperation & Coordination Code of Practice

Photo by August de Richelieu from Pexels.com

In this 30-minute session, we look at the Consultation, Cooperation & Coordination Code of Practice (CC&C CoP). We cover the Commonwealth and Model versions of the CoP, appendices & a summary of detailed requirements; and further commentary. This CoP is one of the two that are generally applicable.

Topics:

- CC&C in the Federal or Commonwealth CoP;

- Extra CC&C in the Model CoP;

- (Watch out for Jurisdiction);

- Further commentary; and

- Where to get more information.

The Risk Management CoP

Photo by Marta Branco from Pexels

In this 40-minute session, we look at the Risk Management Code of Practice (CoP). We cover: who has WHS duties; the four-step process; keeping records, appendices & a summary of detailed requirements; and further commentary. This CoP is the other one of the two that are generally applicable.

Topics:

- Who has WHS duties;

- The four-step process;

- Keeping records, appendices & summary of detailed requirements;

- Further commentary; and

- Where to get more information.

Safe Design

Karolina Grabowska STAFFAGE from Pexels

Want some good guidance on Safe Design? In this 52-minute video from the Safety Artisan, you will find it. We take the official guidance from Safe Work Australia and provide a value-added commentary on it. The guidance integrates seamlessly with Australian law and regulations, but it is genuinely useful in any jurisdiction.

Topics:

- 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.

How to Demonstrate SFARP

Photo by Sondre Dahl from Pexels.com

So our learning objectives for this session at the end of this session, you should understand the SFARP concept: what it’s all about. You should understand the variety of techniques that are available to you. Most importantly, you will be able to apply these techniques in the correct order, because that’s important in the real world.

Topics

- Introduction – Reasonably Practicable;

- How to SFARP with:

- Codes, Standards & Regulations; and

- Controls, or groups of controls.

- Some practical hints on good practice;

- Examples; and

- Source information.
#demonstrateSFARP #reasonablypracticable #reasonablypracticablecaselaw #reasonablypracticabledefinition #reasonablypracticablehealthandsafety #reasonablypracticablemeaning #reasonablypracticablewhs #sfairp #sfairphealthandsafety #SFARP #sfarpsafety #showSFARP #whatdoesreasonablypracticablemean #whatisthebesthealthandsafetycoursetodo #whatisthepurposeofwhs #whsclasses #Whscourse #whscourseonline #whscourses #whstrainingformanagers
Simon Di Nucci https://www.safetyartisan.com/2022/07/06/australian-whs-course/

Comprehensive Project Safety Management Plans: A Guide
Comprehensive Project Safety Management Plans. Safety is a critical element in any large-scale project, especially in the context of defence and complex systems. One essential tool for managing safety is a Safety Management Plan (SMP). In this article, we’ll break down the process and structure of an effective SMP, highlighting its objectives, content, and how to ensure its successful implementation.

Comprehensive Project Safety Management Plans: Introduction

Definitions

A Safety Management Plan is defined as:

“A document that defines the strategy for addressing safety and documents the Safety Management System for a specific project.”UK MoD Defence Standard 00-56

In other words, an SMP serves as a structured approach to managing safety across a project’s lifecycle, ensuring that all risks are identified, analysed, and mitigated effectively.

Objectives

The core objectives of a Project Safety Management Plan are twofold:

- Ensuring Safety Performance: The plan guarantees that the system remains safe throughout its entire lifecycle.

- Maintaining Assurance: It provides the necessary information to demonstrate that safety objectives are being met continuously.

- Achieving these goals requires a coordinated, structured approach that integrates risk management and establishes clear safety requirements right from the start.

SMP in Practice: Contractor vs. Enterprise Project

Each organisation involved in the project—whether it’s the Enterprise Project or a contractor—must produce a distinct SMP that outlines their safety activities. Though separate, these plans should align with each other and the overall project goals. This integration is crucial as safety activities span system development, trials, and any necessary safety approvals.

The SMP discussed here focuses specifically on the Enterprise Project’s plan, which acts as the guiding document for all safety management activities.

Procedure and Methodology

Establishing the Safety Management Framework

The SMP outlines the strategy for ensuring safety and documents the Safety Management System for a particular project. It’s more than just a checklist—it’s a comprehensive program that captures safety timescales, milestones, and other relevant data.

Key areas to be addressed in an SMP include:

- General Equipment Safety: An overarching review of the equipment’s safety features.

- System-Specific Requirements: For example, airworthiness or ship-specific hazards.

- Occupational Safety: Encompassing manual handling, packaging, transport, and more.

- Operational Safety: Ensuring safe procedures during the use phase.

- Maintenance Safety: Guidelines for repair and maintenance activities.

- Training and Disposal: Safety considerations for personnel training and end-of-life disposal of the system.

Creating a Tailored Safety Strategy

No two projects are identical, and neither should their SMPs be. Each plan must be custom-designed to fit the specific project requirements, ensuring a safety strategy that is practical and achievable.

Structuring the SMP: Essential Elements

An effective SMP should contain the following sections:

- Outline Description: Clearly defines the equipment, its purpose, operational environment, and expected capabilities.

- Safety Management System: Details the system’s objectives, managerial tasks, and responsible organisations.

- Responsibilities and Resources: Identifies key personnel and defines their roles through a RACI chart (Responsible, Accountable, Consulted, Informed).

- Audit Arrangements: Outlines internal and independent audit processes.

- Requirements and Acceptance Criteria: Defines safety requirements, targets, and the standards by which success will be measured.

- Safety Case Scope and Strategy: Lays out the assessment strategy and techniques to control hazards.

- Safety Programme: A comprehensive work plan linked to the Through Life Management Plan.

An example template for structuring your SMP can be found in Annexe A. Refer to Annexe B for a sample RACI chart to guide accountability and communication.

Warnings and Potential Project Risks

The SMP is the linchpin of project safety management. If not accurately maintained, the project may face unforeseen delays, increased costs, or compromised safety performance.

Common Pitfalls:

- Inadequate Detail: Missing out on key safety activities can lead to delays and escalated costs.

- Outdated Information: Failing to keep the SMP updated can result in misalignment with the actual safety activities.

- Insufficient Review: Lack of endorsement by the Project Safety Committee (PSC) may mean the plan does not accurately reflect stakeholder responsibilities.

These risks underscore the importance of a thorough, continuously updated SMP.

Procedure Completion and Review

The Project Safety Committee (PSC) is responsible for drafting, endorsing, and reviewing the SMP, ensuring that safety requirements and acceptance criteria are clearly defined and agreed upon by all parties.

Timing:

- Initial Production: Start as early as the Concept stage.

- Ongoing Updates: Review and update the SMP regularly, especially during key project milestones.

The SMP should be a living document that evolves as new information arises or project requirements change.

Safety Planning: Required Inputs

This procedure for Safety Planning requires inputs from:

- Outputs from procedure SMP01 – Safety Initiation;

- Outputs from procedure SMP02 – Safety Committee.

These inputs should be integrated with other management plans throughout the acquisition cycle.

Outputs:

The SMP’s outputs should feed into several project documents, including:

- System Requirements Document: Capture specific safety needs.

- Customer Supplier Agreement: Document mutual agreements on safety deliverables.

- Through Life Management Plan: Align with long-term safety management.

- Business Case Submissions: Support safety-related elements in decision-making processes.

All meeting minutes should reflect decisions made regarding the SMP’s development and upkeep.

Conclusion

The Safety Management Plan is the cornerstone of safety assurance in complex projects. Properly implemented, it serves as a robust framework to manage safety risks, ensure compliance, and maintain confidence in the system’s safety performance throughout its lifecycle.

By following the structure and content outlined in this guide, project teams can create a comprehensive, effective SMP that aligns with the highest standards of safety management.d up-issue.

Safety Planning: Annexe A - Template for a Safety Management Plan

TITLE

Title of equipment or system to be procured with the Requirement reference number.

DESCRIPTION

A brief description of the project, including its purpose and the environment it is to operate in. The scope of the project and interfaces with other equipment are also to be identified.

INVOLVEMENT OF SPECIALIST SAFETY ADVISORS

List any specialist advisors who need to be involved in the program and send them a copy of this plan where required. Such advisers should include internal advisors, external regulators, or statutory bodies that provide advice.

PROJECT SAFETY MANAGEMENT SYSTEM

A description of the Safety Management System within the Enterprise delivery team to include:

- The aims and objectives of the safety management system;

- Technical tasks to be undertaken and the organisation responsible for implementing them;

- Identification of project staff with responsibility for carrying out safety tasks. Include those who are to be issued with letters of delegation;

- Cross-reference to any relevant project safety documents or reports;

- A regime for internal or independent audits of the safety management system;

- Details of the project safety panel;

- Responsibilities, resources, and interfaces with Enterprise, contractor, and specialist advisors;

- Safety reviews, feedback, and reporting procedures;

- Transfer arrangements;

- Design changes;

- Contractor’s trials.

SAFETY REQUIREMENTS

- Safety requirements arising from legislation;

- Enterprise Certification requirements;

- Acceptance criteria;

- Safety requirements from the Requirement or;

- Safety targets;

- Safety-related standards to be applied, e.g. National Standards, Defence Standards, International Standards or overseas standards.

PROGRAMME OF WORK

Identify the tasks that will enable the safety requirements to be met and develop this into a schedule of work on a Gantt or PERT chart, linked to key stages in the Through Life Management Plan.

SAFETY CASE STRATEGY

This strategy should support the program of work above. It will give consideration to the types of analyses and testing to be carried out. It will define the scope of work of the safety case and the interfaces with associated equipment safety cases.

APPROVAL

This plan will be approved by a person with delegated authority.

DISTRIBUTION

Plan to be distributed to the management area with responsibility for in-service support. The plan will also be distributed to teams procuring equipment with which the project interfaces and or interacts.

Annexe B - RACI Chart example

The SMP should contain a RACI Chart to define which authority is Responsible, Accountable, Consulted, or Informed for each of the activities in the Safety Programme. A simple example is given below:

ActivitySafety Delegation HolderProject Safety ManagerIndependent Safety AuditorContractor Project Safety EngineerEquipment UserSafety Case PreparationARIRISafety Case EndorsementAIRIIHazard Log AdministrationAI-R-Safety Requirements PreparationAR-RC

Key: R – Responsible; A – Accountable; C – Consulted; I - Informed

Acknowledgement of Copyright

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

Comprehensive Project Safety Management Plans: What are Your Questions?

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.
#functionalsafetymanagementplanexample #gassafetymanagementplan #healthandsafetymanagementplandoc #healthandsafetymanagementplanexample #healthandsafetymanagementplantemplatenz #healthsafetymanagementplantemplate #ohssafetymanagementplan #safetymanagementplandefinition #safetymanagementplanexample #safetymanagementplanforconstruction #safetymanagementplaninmines #safetymanagementplantemplateqld #sitesafetymanagementplanexample #thelifesafetymanagementplanprovidesinformationandguidelinesforwhichofthefollowing #whatisthepurposeofasafetymanagementsystem
Simon Di Nucci https://www.safetyartisan.com/2024/10/16/comprehensive-project-safety-management-plans/

Project Safety Initiation
In 'Project Safety Initiation' we look at what you need to do to get your safety project or program started.

Introduction

Definitions

A stakeholder is anyone who will be affected by the introduction of the system and who needs to be consulted or informed about the development and fielding of the system, and anyone who contributes to the ultimate acceptance of the project.

We will look at the RACI chart of stakeholders under a later SMP. Top Tip

Project Safety Initiation: Objectives

This procedure describes the start-up of safety management activities on a project. It identifies safety stakeholders and legislative and other standards that need to be satisfied. The procedure also creates the key elements of the safety management organization for the project.

In normal circumstances, this procedure would be applied at the outset of a project, early in the Concept phase. However, it can be applied at any point of the life cycle where it is necessary to initiate a formal safety management process on an existing system. The procedure may also be re-applied at significant points in the life cycle (e.g. after Full Business Case approval), to review and update the project safety arrangements and ensure that they continue to be appropriate.

Remember that a Project delivers on a specific:a) Outcome, result or benefits, e.g. meeting requirements;b) Schedule; andc) Quality criteria, e.g. needed to realise benefits.Top Tip

Comprehensive Guide to Safety Management Procedure Initiation

Safety management is critical to any project, especially those involving complex systems with safety and environmental implications. This procedure outlines the early-stage safety processes that should be followed, assuming that the Program Director has already been appointed and safety responsibilities have been delegated to a competent team member within the delivery team. The goal of safety initiation is to ensure that safety management starts on a firm basis, identifying crucial stakeholders, regulatory authorities, and internal teams responsible for safety and environmental protection.

In this article, we will provide an in-depth understanding of the safety initiation process, stakeholder identification, project safety organization creation, compliance considerations, and necessary documentation.

Purpose of Safety Initiation

The primary objective of safety initiation is to commence the safety management process by:

- Identifying stakeholders, regulators, and approval authorities.

- Appointing a Project Safety Manager (PSM) and, if required, an Independent Safety Auditor (ISA).

- Forming the Project Safety Committee (PSC).

- Ensuring compliance with safety and environmental regulations and creating a responsible, accountable, consulted, informed (RACI) chart.

This procedure helps mitigate risks to project timelines, cost, and overall safety by ensuring safety requirements are identified and met early in the project lifecycle.

All applicable factors need to be lined up to ensure the success of a safety project or program.Top Tip

Project Safety Initiation: How It's Done

1. Stakeholder Identification in Safety Initiation

The identification of stakeholders is crucial. Stakeholders include any individuals or groups impacted by the project’s development or operation, as well as those responsible for the project's approval and compliance. This may include industry professionals, regulatory bodies, and environmental authorities. Here’s how to systematically identify and involve relevant stakeholders:

Who Are the Stakeholders?

A stakeholder is defined as anyone affected by the system or involved in its acceptance, including:

- Individuals who are responsible for safety at any stage of the project.

- Groups or individuals with safety information or requirements relevant to the project.

- Subject Matter Experts (SMEs) with specialized knowledge critical to project safety.

Consulting Key Stakeholders

At a minimum, the following must be consulted:

- Project Sponsor (e.g., Director of the End Users’ Business Unit).

- Equipment Users who will be directly affected.

- Director Technical responsible for the technical aspects of the project.

- Safety & Environmental Protection Group tasked with compliance.

- Other Delivery Teams involved with subsystems or associated projects.

After identifying stakeholders, record their involvement and details in Form SMP01/F/02 - Register of Stakeholder Requirements and Information. External stakeholders such as other government departments or industry experts should also be logged into the communication plan. For complex projects, develop a communication plan outlining stakeholder contact details, responsibilities, and relevant security considerations.

It may be helpful to rename the project communication plan the Project Stakeholder Management Plan - what do you need from stakeholders for your Project to succeed?Top Tip

2. Ensuring Compliance with Safety Regulations

Compliance with safety and environmental regulations is a critical responsibility of the Delivery Team. The following methods ensure compliance across various safety aspects:

Key Compliance Strategies:

- System Specifications: Delivery Teams develop specifications to meet user requirements, ensuring safety and environmental standards are incorporated.

- Through Life Management Plan (TLMP): This plan outlines the long-term impact of safety and environmental legislation on equipment.

- Enterprise Guidance: Use internal guidelines when creating contracts to include safety and environmental performance targets.

Sources for Regulatory and Legislative Information:

To maintain compliance with safety and environmental legislation, teams can access a wide range of resources, including:

- Legislative registers held by the program teams.

- Defense Regulator intranet pages.

- Health & Safety Executive publications and other professional societies.

- Suppliers, contractors, and consultants with expertise in safety and environmental law.

The Delivery Team must identify applicable legislation at the start of the project and continuously update a legislative register as part of the Safety Case.

For more information on this vital task, see the post on System Requirements Hazard Analysis here.Top Tip

3. Creating a Project Safety Organization

Establishing a robust safety management structure is essential to ensure compliance with safety standards and regulations. The Safety Management Plan (SMP) will eventually document the project’s entire safety organization, but before that, some key safety roles need to be defined.

Steps to Set Up Project Safety Organization:

Develop a Project Safety RACI Chart: This chart defines who is Responsible, Accountable, Consulted, and Informed at different stages of the safety process.

Appoint a Competent Project Safety Manager (PSM): This individual is responsible for overseeing safety management throughout the project.

Appoint an Independent Safety Auditor (ISA): For complex or high-risk projects, appointing an ISA is advisable. The ISA ensures that safety audits are conducted independently.

Form a Project Safety Committee (PSC): This group will be responsible for monitoring and governing safety issues within the project.

3. Ensuring Compliance with Safety Regulations

Compliance with safety and environmental regulations is a critical responsibility of the Delivery Team. The following methods ensure compliance across various safety aspects:

Key Compliance Strategies:

- System Specifications: Delivery Teams develop specifications to meet user requirements, ensuring safety and environmental standards are incorporated.

- Through Life Management Plan (TLMP): This plan outlines the long-term impact of safety and environmental legislation on equipment.

- Enterprise Guidance: Use internal guidelines when creating contracts to include safety and environmental performance targets.

Sources for Regulatory and Legislative Information:

To maintain compliance with safety and environmental legislation, teams can access a wide range of resources, including:

- Legislative registers held by the program teams.

- Defense Regulator intranet pages.

- Health & Safety Executive publications and other professional societies.

- Suppliers, contractors, and consultants with expertise in safety and environmental law.

The Delivery Team must identify applicable legislation at the start of the project and continuously update a legislative register as part of the Safety Case.

4. Safety Documentation and Records

Documenting safety processes ensures accountability and maintains a clear safety management trail. These records feed into critical project documentation, including:

- System Specification: Defines specific safety requirements.

- Customer-Supplier Agreement: Documents agreements on safety information.

- Through Life Management Plan (TLMP): Outlines the ongoing safety and environmental impact.

- Safety Elements in Business Case Submissions: Ensures all safety-related information is considered in formal project submissions.

Outputs to Record:

Appointed PSM and ISA, if appropriate;

SMP01_F_01 - Safety Operating Environment QuestionnaireDownload

SMP01_F_02 - Register of Stakeholder Requirements and InformationDownload

SMP01_F_03 - Register of Safety Legislation and Other Significant RequirementsDownload

Proper documentation supports future audits, stakeholder engagement, and compliance efforts. Competent to perform the required responsibilities.

5. Importance of Competence in Safety Management

Competence in safety management is key to project success. The competence of the PSM and ISA must be demonstrated and documented to assure that they can effectively discharge their safety responsibilities.

Consequences of Incompetence or Delays:

Failure to appoint competent individuals or delay the initiation of safety management procedures can lead to:

- Increased risk to project timelines and costs.

- Delayed engagement with stakeholders.

- Overlooked safety and environmental requirements.

Conclusion: Importance of Early Safety Management Initiation

Initiating a structured safety management process at the early stages of a project is crucial for ensuring compliance with safety and environmental standards. By identifying stakeholders, setting up a robust safety organization, ensuring compliance, and maintaining accurate documentation, the project minimizes risks, avoids delays, and maintains clear communication with all involved parties.

Project Safety Initiation: Timing

Initial Application

In an acquisition program, the procedure should be carried out early in the Concept phase.  Stakeholders, system boundaries, supporting systems/arrangements, and acceptance authorities need to be identified as early as possible to support the subsequent Preliminary Hazard Identification activity (Procedure SMP04 – Preliminary Hazard Identification) and the preparation of the SMP.

The procedure can be applied at any point of the life cycle where it is necessary to initiate a formal safety management process.

Review

The registers of stakeholders and requirements should be reviewed and updated after the Outline Business Case and Full Business Case as part of the review and update of the SMP.

New Safety Managers could also use this as a take-over checklist, to make sure all necessary decisions have been made and clearly documented.Top Tip

Acknowledgment of Copyright

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

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.
#EnvironmentalSafetyRegulations #IndependentSafetyAuditor(ISA) #LegislativeComplianceinProjects #projectandstakeholdermanagement #projectcharterstakeholderlistexample #projectgovernancestakeholdermanagement #projectmanagementstakeholderlist #ProjectSafetyOrganization #projectstakeholderanalysisexample #projectstakeholdercommunicationplan #projectstakeholderlisttemplate #projectstakeholdermanagementbestpractices #projectstakeholderregisterexample #SafetyCompliance #SafetyDocumentation #SafetyManagementPlan(SMP) #SafetyManagementProcess #SafetyRACIChart #StakeholderIdentification #whoisprojectstakeholder
Simon Di Nucci https://www.safetyartisan.com/2024/10/02/project-safety-initiation/

Understanding Your Risk Assessment Standard
When Understanding Your Risk Assessment Standard, we need to know a few things. The standard is the thing that we're going to use to achieve things - the tool. And that's important because tools designed to do certain things usually perform well. But they don’t always perform well on other things. So we will ask, ‘Are we doing the right thing?’ And ‘Are we doing it right?’

This post is part of a series:

- Intro to System Safety Risk Assessment

- Start of System Safety Risk Assessment

- Hazard & Risk Basics (SSRAP Module 1)

- System safety risk analysis (SSRAP Module 2)

Video Highlights

Understanding Your Standard: Highlights

Transcript

What and Why?

So, what will we do and why are we doing it? First, the use of safety standards is very common for many reasons. It helps us to have confidence that what we're doing is good enough. We've met a standard of performance in the absolute sense. It helps us to say, ‘We've achieved standardization or commonality in what we're doing’.

We can also use it to help us achieve a compromise. That can be a compromise across different stakeholders or different organizations. Standardization gives us some of the other benefits as well. If we're all doing the same thing rather than we're all doing different things, it makes it easier to train staff. This is one example of how a standard helps.

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

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

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

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

System Safety Pedigree

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

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

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

This is Module 3 of SSRAP

'Understanding Your Risk Assessment Standard' is Module 3 of the System Safety Risk Assessment Program (SSRAP) Course. Risk Analysis Programs – Design a System Safety Program for any system in any application.

The full course comprises 15 lessons and 1.5 hours of video content, plus resources. It's on pre-sale at HALF PRICE until September 1st, 2024. Check out all the free preview videos here and order using the coupon “Pre-order-Half-Price-SSRAP”. But don't leave it too long because there are only 100 half-price courses available!

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.
#Achievingcomprehensivesystemsafetyassurance #Benefitsofusingsafetystandardsforcomplexsystems #Bestpracticesformanagingsafetyrisks #Bestsystemsafetyengineeringstandard #Comprehensivesafetyanalysistoolsandsoftware #Developinganeffectivesafetyprogram #Effectivehazardidentificationandanalysismethods #Ensuringhighperformancesystemsafety #Howtoimplementsystemsafetyriskanalysisprograms #Implementingengineeringsafetystandards #Legalsafetycompliancetoolsandresources #Meetingcomplexsystemsafetyrequirements #Meetingsafetyrequirementsforhighrisksystems #Safetystandardsformilitaryequipmentsystems #Systemsafetysolutionsforlargeprograms #Tailoringsystemsafetyprogramsforspecificneeds #Toolsforimplementingsafetystandardseffectively #Topriskanalysisstandardsforsafetyprograms #Understandingthepedigreeofsystemsafetystandards #WheretobuyMilitaryStandard882Ecompliancetools
Simon Di Nucci https://www.safetyartisan.com/2024/08/28/understanding-your-risk-assessment-standard/