Functional Safety Engineer: an interview with Tomasz Łokietek

In this installment of our ‘Spyrosoft People‘ series, we’re talking with Functional Safety Engineer, Tomasz Lokietek.

What does a Functional Safety Engineer do?

Depending on the size of the company, the project and the workflow, companies create the role of Functional Safety Engineer to support the product development process. A person who has been previously involved in hardware/software/systems architecture design, may also be nominated and tasked with additional responsibilities regarding Functional Safety. Functional Safety is important for all these areas and it covers all elements of the product life cycle – from the initial idea to scrapping the final product. The Functional Safety Engineer will have different responsibilities depending on which area they are allocated to, and they will also have different tasks to complete.

If we narrow it down to software development, the Functional Safety Engineer must ensure that the requirements for product safety are in place. Often, they are also in position to explain the concept of safety to other team members and make sure that the safety requirements are not only implemented but also, consistent with how systems engineers defined these on a system level. The Safety Engineer also serves as a consultant who helps to find a solution for aligning processes with safety requirements. They also arrange it so these processes would not hinder the project’s completion. More often than not, it’s achieved by selecting the most crucial items and requirements in the Functional Safety process.

When it comes to software itself, the Functional Safety Engineer verifies components, elements and documentation that are related to safety. They also conduct safety analyses – checking solutions proposed by Software Architects against the existing system’s safety requirements and whether these solutions can be implemented in line with the requirements. They also make sure that the solutions don’t add to the current list of product risks.

They also support developers in setting coding guidelines. When the team wants to derogate from the process, they create supporting explanations on why the derogation had to be made and why it would still be safe.

Another task is analysing any external documents coming from our suppliers. Before we add a new component or a library, we have to check whether these elements can impact product safety. We have to estimate the degree to which this has impact, especially if it’s negative, and what we could do to ensure that the product is still safe after adding this new element. We often find ourselves in a position where our clients propose solutions that may not be secure, so we inform them of the hazards when using these solutions (i.e. not gaining a certification, not completing an audit, technological debt).

A huge part of every Functional Safety Engineer’s role is analysing the tools. If we want to include a certain tool in the product development process or in the implementation of a safety-critical element, this tool has to be secure, meaning that it doesn’t have any errors that can negatively affect the quality of the final product.

Functional Safety Engineer vs Functional Safety Manager

A Functional Safety Manager takes care of all the tasks I’ve mentioned above, plus any aspects related to introducing and promoting the so-called safety culture within an organisation. One of the key elements of safety culture is not looking for someone responsible when mishaps occur.

Instead, the team’s efforts should be focused on finding a solution. This approach ensures a comfortable and healthy environment where it is possible for team members to point out their own mistakes or highlight any project risks. The ultimate goal is not searching for scapegoats, but rather delivering a safe product.

A Functional Safety Manager is someone who’s deeply involved in defining the safety processes in an organisation and is always setting the criteria for quality products and product processes. Their priority is ensuring the product is secure.

They are also responsible for preparing a very important document, a safety case. A safety case includes examples to show that we completed our work in line with the safety processes defined within the organisation and collected throughout the product development process. It is also crucial for declaring that our product is secure.

How did you get into Functional Safety?

It was a conscious decision based on the opportunity I was given. I graduated from Electronics at the Technical University and at the beginning, I was responsible for testing products with automatic machines at one of the automotive companies in Wroclaw, Poland. Then I moved to their Research&Development department where I was working on developing electronic car devices. One of the projects I was involved in was testing braking support systems. I could see how testing could work in the context of safety standards, risk estimation and verifying critical functions. Then I became Global Director for verifying and validating electronic products, still focusing on hardware. My next role was in testing and security at a software development company and that’s how I moved into software.

What is your approach to brand new projects? What draws your attention?

In the initial phase, I always focus on the areas that should be included in the software development process. With each project, you must go through it anew, even it includes a new generation of software or its new variant. The first thing that you should complete is analysis of how these software changes impact the product. Based on that, I then understand whether the changes were critical to safety.

As a rule, the subject of safety can be divided into two different categories. The first one is related to technical safety planning where we define what should happen when one of the critical functions that keeps the user safe, stops working. The second category refers to the fact that even if your initial idea is phenomenal, if the execution is lacking, the final product will not function well. This is the process aspect of product safety and it’s heavily influenced by Functional Safety. We can minimalise the process’ need for extra resources by identifying points that can be adjusted, kept intact or added. Understanding the process of developing a product and aligning it with the safety requirements is often the key to limiting the number of resources necessary for completing the project. It is also essential for fulfilling the quality requirements all at once.

Which safety tool are we using at Spyrosoft?

The truth is that you don’t need any tools for safety projects. You can prepare it all in Excel or Word but executing it would not be as pleasant and smooth for the Safety Engineer and the rest of their team [laughs].

At Spyrosoft, we’re using Ansys Medini which allows us to conduct a number of safety analyses, including FMEA/FMEDA and FTA. We can also use it to manage a database of safety mechanisms where, for every risk we also have to define a safety mechanism. Additionally, thanks to Medini, we can connect with popular software development tools, including PTC Integrity, DOORS and EnterpriseArchitect. We can then generate a safety case report.

What type of documentation and processes should a company have in place before they come to Spyrosoft with a safety-related project?

It all depends on the process maturity of the company and on how mature the technology is that they would like to use. If we want to develop – say – a combustion engine control or the electronics used in this type of engine, we can use an existing standard model called I-GAS. We also have a defined safety model. If a car is safe enough to drive in regular traffic, then it is safe enough to be driven around an airport or a business exhibition.

I would also ask their team about the stage they’ve reached of the product development process. If they are still defining system requirements, then their business requirements should be enough for us to start designing system architecture and therefore make a list of system requirements.

However, we would serve as a supporting team or if we were responsible for developing the software, we would need to have to have this system level defined, with a draft architecture, documentation and a list of system requirements available. Saying that, we have also worked on projects where none of these elements existed and we were still able to help.