Safety Plan

[autonomtech]

Hi everybody,

I am the CEO and Safety Manager of Mechatnom. I would like to contribute with my experience and expertise on safety.

As I see, there is no merged documents in our repository. Basically, there is no safety without any plan that's why my suggestion is to create a safety plan. After creating plan, for sure new documents are needed to be established such as FMEA, Software FMEA, Dependent Failure Analysis and more.

What do you think?

[slivingston]

Of course. Can you propose a plan?

[doganulus]

As for ISO26262 compliance and safety standards, while it is essential for any autonomous system to meet these standards, it is also important to understand the role of the open-source community in this process.

Nope. Safety comes first. Did you read the table I sent? Safety must be more important than your business, your heritage, and your traditions. You should live and breathe safety to develop safety-critical systems. This is not open to discussion (sorry).

I speak from the book. Please read ISO26262 and find arguments that demonstrate evidence against my claim. This is a great exercise for anyone.

You are making it seem like we are suppressing the dissenting voices. But in reality, we are just trying to keep discussion healthy. You are not a whistle-blower, you are not a suppressed voice.

I do not have such a claim for the AWF. I am talking about the ROS community. Again, it is a problem when developers prioritize heritage over safety. Prioritizing anything other than safety (business, reputation) is a safety problem.

Then I have to make it a trouble. Someone has to make it a trouble. This is my open-source contribution.

What was the last time you've:
...

You only think of the software level. Before coming to the software level, ISO26262 defines the layers of

• Safety management
• Safety concept
• System safety
• Software safety

In this thread, I have identified 5-6 violations in safety management. And unfortunately, it is counting. It is like a container layer caching; a mistake in earlier layers invalidates the following layers. Maybe this way could be more understandable for software engineers. Those critical bugs in your software does not happen if you design your software better, for example. If you develop a safety culture, you would not do nonsense design decisions. Safety comes from the whole.

That's why you have a hard time grasping that it is not about commits and PRs. These threads create awareness on the topic. Every developer who develops safety-critical software must live and breathe safety.

But again please do not use open-source as an excuse for poor quality and unsafe practices. I know you will do but please don't.

[xmfcx]

You are clearly passionate about safety, but you’re not helping. Your approach is becoming more of a hindrance than a contribution.

Nope. Safety comes first. Did you read the table I sent? Safety must be more important than your business, your heritage, and your traditions. You should live and breathe safety to develop safety-critical systems. This is not open to discussion (sorry).

We all agree on the importance of safety. We are not compromising safety for heritage or traditions. Constantly berating the community without offering constructive solutions is counterproductive.

I speak from the book. Please read ISO26262 and find arguments that demonstrate evidence against my claim. This is a great exercise for anyone.

Your reference to ISO26262 is noted, but it's not a shield for dismissive behavior or unfounded criticism. We are committed to safety, but we also believe in collaboration and constructive actions. Simply quoting standards without engaging in meaningful dialogue or providing actionable solutions is disruptive. Instead of continually pointing out flaws, contribute to the solution or step aside and let those committed to real progress continue their work.

I do not have such a claim for the AWF. I am talking about the ROS community.

Your broad generalizations and continuous complaints are affecting the morale of the community. Constructive criticism is welcome, but your manner is creating friction instead of fostering improvement.

Then I have to make it a trouble. Someone has to make it a trouble. This is my open-source contribution.

Making trouble is not a contribution. Constructive dialogue, actionable feedback, and actual contributions to the codebase or documentation are contributions. Your current approach is disruptive, not helpful.

You only think of the software level.

Yes, we focus on software because that’s where practical improvements can be made. Your vague criticisms without actionable steps help no one. If you truly believe in the layers of safety management, show us by contributing in a way that addresses these layers constructively.

In this thread, I have identified 5-6 violations in safety management. And unfortunately, it is counting.

Let’s be clear: moderating discussions to keep them productive and respectful is not a safety violation, nor is it “groupthink.” It’s about maintaining a professional and constructive environment for everyone involved.

You’ve mistaken moderation for suppression. We value intellectual diversity and constructive criticism when it’s actually constructive. But you have consistently failed to engage in a way that fosters improvement. Instead, you derail conversations and attack the community’s integrity without offering real solutions.

Those critical bugs in your software does not happen if you design your software better, for example.

We know our software isn't perfect. That’s why we have an open-source community: to collaborate, identify, and fix these issues together. If you truly care about safety, help us by contributing directly to these fixes.

These threads create awareness on the topic. Every developer who develops safety-critical software must live and breathe safety.

We get it. Safety is paramount. But awareness without action is futile.

But again please do not use open-source as an excuse for poor quality and unsafe practices. I know you will do but please don't.

We’re not using open-source as an excuse. Open-source projects thrive on collaboration, respect, and actionable contributions. Your relentless complaining, without taking any steps to help improve the project, undermines these principles.

I'm really tired of your baseless accusations and unproductive negativity.
Either contribute constructively, with actionable feedback and real solutions, or stop disrupting the community.
We’re here to build, improve, and innovate. If you can’t be part of that, at least don’t stand in the way.

[mitsudome-r]

@doganulus I apologize that we removed the conversation without any warnings. However, I am positive that Fatih's intention was to keep the thread focused on the original post, and it wasn't intended to hide any evidence. (In fact, he took the screenshot before removing the conversation.) Now that the original conversation is traceable from the screenshot, I hope we can all go back to the original discussion.

I think we are all just waiting for @autonomtech to post his Safety Plan template for now.
If anyone wants to discuss anything important other than the safety plan or it's template, then please create another discussion.

[doganulus]

@mitsudome-r I do not assume any bad intentions. The commitment to safety must be encouraged by all means. Fatih (@xmfcx) and others will see better as time passes why I have a hard uncompromising approach when it comes to safety and good software development practices.

Safety processes are never easy but it develops with a persistent proactive attitude. Some professional training might be considered across member organizations.

[autonomtech]

@doganulus I apologize that we removed the conversation without any warnings. However, I am positive that Fatih's intention was to keep the thread focused on the original post, and it wasn't intended to hide any evidence. (In fact, he took the screenshot before removing the conversation.) Now that the original conversation is traceable from the screenshot, I hope we can all go back to the original discussion.

I think we are all just waiting for @autonomtech to post his Safety Plan template for now.
If anyone wants to discuss anything important other than the safety plan or it's template, then please create another discussion.

Hi, I can post the template for sure. However, I want to work according to the Autoware process. After discussions are saturated, a task will be opened and under the task, work will be done as long as I understood from Autoware Procedere.

[doganulus]

Hi @autonomtech,

That's an admirable idea. Yet the ROS community, which most Autoware developers belong to, is mainly unaware of safety-critical software development, which is indispensable in the automotive sector, as you know. The Autoware community would be happy if you had a magical safety tool/plan. However, roles, responsibilities, and well-defined processes are not in the vocabulary of regular ROS developers and architects. This is a safety culture problem, as you may have identified.

There were previous attempts to discuss safety issues in the community, such as ROS Safety WG, but such attempts apparently faded quickly. The Autoware organization was promising initially but couldn't show the necessary courage to lead safety efforts. Unfortunately, this year, I am observing a regression towards unsafe practices of the ROS community. Of course, without safety compliance, Autoware would stay as a large hobby project, but the community is unaware of that, as I said.

My suggestion would be: Based on your experience in the automotive sector; it may be helpful to list all the discrepancies at the process level you have observed in Autoware. I mean things like the lack of a safety manager and safety plan. Probably, your educated eye would detect more. But this discussion board wouldn't be so helpful in terms of feedback.

Thank you for your initiative anyway!

[autonomtech]

Hi @doganulus,

Thank you for your comment.

Topic of this discussion is to establish a Safety Plan and first step of contribution is the discussion. After discussions are saturated, an issue will be opened if needed and the related task will be done under issue. So that's why this discussion board will be helpful according to the Autoware process. Opened discussions will be also discussed in the regular meetings.

First steps for safety assurance are to have safety plan and safety lifecycle which also includes also all activities to provide safety culture in the organisation.

M.Eng. Can Acar

[doganulus]

Ok, I stirred the thread. Let's see. Hope you get the feedback you want.