Where Does Safety Live in Your Organization?

Where Does Safety Live?

The first three pieces in this series looked at the safety case itself: how it carries forward after certification, how evidence flows back into it, and how its links hold together when something changes. This piece looks at the organization around it, starting with something Steven Marks, Fennec's Director of Product, has noticed many times over his career, and that he is speaking about at the International Robot Safety Conference in Detroit on November 5th.

A clue in the folders

When a team adds him to its functional safety folder in SharePoint or Google Drive, he often finds a structure like the one in Figure 1. A program folder holds an engineering folder, which holds development, then systems engineering, then safety, and finally functional safety, like the smallest doll in a set of nesting dolls.

A folder structure is just a folder structure. Still, it can reflect how a program thinks about safety. When functional safety sits at the bottom of the tree, it can start to look like a separate track focused on compliance, running alongside the engineering work rather than through it.

Turning the structure around

Figure 2 shows an alternative. Safety sits directly under the program, and inside functional safety sits hardware, firmware, test, and integration.

A folder structure is just a folder structure. Still, it can reflect how a program thinks about safety. When functional safety sits at the bottom of the tree, it can start to look like a separate track focused on compliance, running alongside the engineering work rather than through it.

Turning the structure around

Figure 2 shows an alternative. Safety sits directly under the program, and inside functional safety sits hardware, firmware, test, and integration.

This is less about reorganizing folders than about treating safety as a design decision the whole team shares, made early in a program rather than checked off at the end. It also mirrors the safety case itself. As the previous piece in this series showed, the links in the chain come from different disciplines: hazard analysis from safety engineers, element design from hardware and firmware engineers, test evidence from test teams. Figure 2 puts the people where the safety case already puts their work.

It matters for change and change management, too. The first piece in this series described three sources of change: the operating environment, the hardware, and the software. Each tends to start with a different group, whether that is a commercial decision, a supplier change, or a new software release. An impact analysis can only assess changes that have been formally identified and communicated, and a safety-centered structure helps ensure those changes are captured early enough to evaluate their implications for the safety case.

Bringing more people into the work

The inverted structure is also a way to involve people outside the safety team, which can be one of the harder parts of the work. Functional safety has a vocabulary that takes time to learn: Safety Integrity Levels (SIL), Performance Levels (PL), diagnostic coverage, Safe Failure Fraction (SFF). Standards like IEC 61508-3 and ISO 13849 are dense, and it is reasonable that engineers outside the safety team do not live in them day to day.

Some of the most important translation work also depends on those engineers. The annex tables in these standards describe techniques expected at a given integrity level, such as static code analysis for safety-related software. Turning those tables into requirements a team can act on takes people who know the code and the circuits.

One approach that helps is involving hardware and firmware engineers early in the safety process, during the hazard and risk assessment, rather than handing them a finished requirements specification and expecting them to design the system properly. When a firmware engineer can see how developing a diagnostic may impact the Risk Assessment, the work takes on a clear purpose: this is how the code keeps people safe.

Safety as a habit

Safety culture tends to take root from the top. Picture two programs working toward the same certification. In one, an engineering leader sets the expectation that firmware will be developed to IEC 61508-3 from the start. The mandate may be unpopular at first, but the team adjusts, and the practices become part of the work. In the other, a functional safety engineer is left to persuade colleagues, one conversation at a time, that the work SIL 2 certification requires is real: that it is complex, that it takes time, and that it is necessary. The standards are the same in both cases. The difference is where the expectation comes from.

That is why habit is a useful way to think about it. A new practice can feel like a burden at first and then become simply how the work gets done. Safety and quality are two sides of the same coin, and the discipline that keeps a safety case current, with clear requirements, traceable decisions, and repeatable tests, is the same discipline that produces a well-engineered product.

Where does safety live in your organization?

There is no single right structure, and every organization will answer this differently. But it is a question worth asking, because the answer shapes how early change reaches the safety case, how many people understand the reasoning inside it, and how naturally it keeps learning.

Fennec Engineering is a team of functional safety engineers who build software. The ASAP Platform gives every discipline shared visibility into one connected safety case, from the first risk assessment to the latest test result.