(기능안전 13강) Safety Goal 설정과 검토 포인트 – 실무자는 이렇게 한다!

🛡️ 13강. Safety Goal 설정과 검토 포인트 – 실무자는 이렇게 한다!

안녕하세요, 
오늘은 HARA 이후, 가장 중요하면서도 가장 오해받기 쉬운 단계,
바로 Safety Goal(안전 목표) 설정에 대해 알아봅니다!

"Safety Goal? 그냥 '안전하게 만들자' 쓰면 되는 거 아닌가요?"
No No! 🙅‍♂️ Safety Goal은 ISO 26262에서 법적·기술적으로 가장 중요하게 여기는 문장입니다.
HARA 결과를 기반으로 명확하게 정의되어야 하고,
이후 모든 개발 단계에서 중심 기준이 되는 바로 그 목표죠!

---

🎯 1. Safety Goal이란?

ISO 26262-3:2018에 따르면, Safety Goal이란:

"식별된 위험(Hazard)에 대해 발생 가능한 부정적인 영향을 방지하거나 줄이기 위한 상위 수준의 안전 요구사항"

즉, ASIL을 반영한 '목숨을 지키기 위한 약속' 같은 개념입니다.

---

🧠 2. Safety Goal은 어떻게 정의하나요?

✅ 기본 규칙

1. HARA 결과를 기반으로 한다.
2. 기능의 부정적인 효과를 피하도록 기술해야 한다.
3. 단순하고 구체적인 문장으로 작성한다.
4. ASIL을 명확히 부여해야 한다.

💬 작성 포맷 예시

차량이 정지 중일 때, 전자식 파킹 브레이크의 작동 실패로 인한 차량 후진을 방지해야 한다. (ASIL D)

이렇게 작성하면 개발자는 “아, 우리는 차량이 움직이지 않도록 무조건 막아야겠구나!” 하고 이해할 수 있어요.

---

🔍 3. 실무에서 자주 쓰이는 Safety Goal 예시

🚙 전자식 파킹 브레이크(EPB)

• SG1: 주차 중 파킹 브레이크 작동 실패로 인해 차량이 이동하는 것을 방지해야 한다. (ASIL D)

🚗 전자식 스티어링(EPS)

• SG2: 차량 주행 중 스티어링 보조기능의 고장으로 인한 조향 불가능 상태를 방지해야 한다. (ASIL C)

🚦 ADAS 차선 유지 보조(LKA)

• SG3: 차선 유지 기능 오작동으로 인한 차량 비정상 이탈을 방지해야 한다. (ASIL B)

🛑 자동 긴급 제동(AEB)

• SG4: 전방 차량을 인식하지 못해 충돌을 야기할 수 있는 시스템 고장을 방지해야 한다. (ASIL D)

---

🧾 4. 검토할 때 꼭 확인해야 하는 포인트

체크 항목	설명
✅ HARA에서 유도된 것인가?	HARA의 Hazard ID와 연계되어 있어야 함
✅ 기능 설명과 연계되었는가?	시스템의 주요 기능을 정확히 반영하고 있는가
✅ 단어가 추상적이지 않은가?	“적절히” “가능하면” 같은 모호한 표현은 피하기
✅ ASIL이 일관된가?	HARA 결과의 S-E-C를 반영한 ASIL을 정확히 표기했는가
✅ 너무 많거나 적지 않은가?	Safety Goal이 많으면 설계·테스트 복잡도 급상승! 꼭 필요한 목표만 추출

---

🔄 5. 실무 팁: Safety Goal은 협업의 산물이다

• 기능안전팀 단독 작성 → ❌
• 반드시 개발자, 기획자, 시스템 엔지니어와 협업해서
  현실적인 목표로 작성해야 실제 구현이 가능해요.

🎯 목표는 높되, 현실과 동떨어지지 않도록!

---

 

🏁 오늘의 요약

• Safety Goal은 HARA 결과를 기반으로 도출된 상위 안전 요구사항
• 실무에서는 모호한 표현 없이, 간결하고 구체적으로 작성해야 함
• ASIL을 명확히 반영하고, 검토 항목을 체크하면서 관리 필요
• 팀 협업과 문서 추적성 확보는 필수!

---

🔮 다음 강 예고

Safety Goal까지 설정했으니, 이제 뼈대를 만들어야겠죠?

14강: Functional Safety Concept 작성법 – 뼈대 세우기

• FSC의 구조는 어떻게 생겼을까?
• Safety Goal을 어떻게 기술 요구사항으로 풀어낼까?

실무형 FSC 작성 꿀팁, 다음 강에서 알려드립니다! 🧱📘