Ingénieur en sécurité fonctionnelle : entretien avec Tomasz Łokietek

Dans ce volet de notre ‘Spyrosoft Peoplesérie, nous nous entretenons avec Tomasz Lokietek, ingénieur en sécurité fonctionnelle.

Que fait un ingénieur en sécurité fonctionnelle ?

Selon la taille de l'entreprise, du projet et du flux de travail, les entreprises créent le rôle d'Ingénieur en Sécurité Fonctionnelle pour soutenir le processus de développement produit. 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.

En ce qui concerne le logiciel lui-même, l'ingénieur en sécurité fonctionnelle vérifie les composants, les éléments et la documentation liés à la sécurité. 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.

Ils accompagnent également les développeurs dans la définition des directives de codage. Lorsque l'équipe souhaite déroger au processus, ils rédigent des explications justifiant la nécessité de la dérogation et démontrant qu'elle reste sûre.

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.

Ingénieur en sécurité fonctionnelle vs Responsable en sécurité fonctionnelle

Un Functional Safety Manager prend en charge toutes les tâches que j'ai mentionnées ci-dessus, ainsi que tout aspect lié à l'introduction et à la promotion de ce que l'on appelle la culture de sécurité au sein d'une organisation. L'un des éléments clés de la culture de sécurité consiste à ne pas chercher un responsable lorsque des incidents se produisent.

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.

Un responsable de la sécurité fonctionnelle est une personne profondément impliquée dans la définition des processus de sécurité au sein d'une organisation et qui établit en permanence les critères pour des produits et des processus de production de qualité. Sa priorité est de garantir la sécurité du produit.

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.

Comment avez-vous débuté dans la sécurité fonctionnelle ?

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.

Quelle est votre approche pour les projets entièrement nouveaux ? Qu'est-ce qui attire votre 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.

Quel outil de sécurité utilisons-nous chez Spyrosoft ?

La vérité, c'est que vous n'avez besoin d'aucun outil pour les projets de sécurité. Vous pouvez tout préparer dans Excel ou Word, mais son exécution ne serait pas aussi agréable et fluide pour l'ingénieur sécurité et le reste de son équipe [rires].

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.

Quel type de documentation et de processus une entreprise devrait-elle avoir en place avant de venir chez Spyrosoft avec un projet lié à la sécurité ?

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.