🛡️ 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. 검토할 때 꼭 확인해야 하는 포인트

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

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

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

🏁 오늘의 요약

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

🔮 다음 강 예고

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

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

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

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

⚠️ 12강. HARA(위험 분석 및 위험성 평가) – 실무 팁과 예시 대방출!

안녕하세요, 오늘도 안전하게 기능안전! 👷‍♂️🚗
이번 강의는 드디어 기능안전의 꽃, HARA (Hazard Analysis and Risk Assessment)입니다.
"위험을 알아야 막을 수 있다!"
오늘은 실무에서 진짜 사용하는 방식으로 HARA를 어떻게 작성하고 적용하는지 알려드릴게요!

그리고 중요한 포인트!
오늘의 핵심은 바로 “운용 환경 조건을 반드시 반영하라!”입니다.
실무에서는 환경 조건 미반영이 HARA 실패의 주범입니다! ⚠️

🧭 1. HARA란 무엇인가?

HARA는 한 줄로 말해

“위험한 상황을 미리 찾아내고, 그 위험을 수치로 표현해
적절한 안전등급(ASIL)을 부여하는 분석”입니다.

ISO 26262-3:2018 기준에 따르면, HARA의 핵심 목표는 다음과 같습니다.

• Hazard identification (위험요소 식별)
• Operational scenario 정의 (운용 조건 및 상황 설정)
• Risk 평가 (S, E, C 기준에 따른 ASIL 결정)

🧪 2. 실무 절차 – 이렇게 작성해요!

1️⃣ Item Definition 기반 운용 시나리오 도출

예를 들어, 전자식 파킹 브레이크(EPB)의 경우

• “언덕에서 정차 후 브레이크가 자동으로 걸리지 않음”
• “주행 중 브레이크 오작동으로 갑작스런 정지”

이런 시나리오를 도출합니다.

✨ 팁: 시나리오는 너무 많아도 너무 적어도 안 됩니다. 대표적, 현실적, 반복 가능성 있는 것으로 뽑아야 해요.

2️⃣ Hazard 도출 (고장 시나리오와 연결)

운용 시나리오에서 위험 상황을 정의합니다.

3️⃣ 환경 조건 반영 – 이게 핵심이다! 🧊🔥💨

실무에서 가장 놓치기 쉬운 부분이 바로 환경 조건 반영입니다!

예시 조건

• 온도: -40°C ~ +85°C
• 배터리 전압: 9V ~ 16V
• 진동/EMC 조건: ISO 7637, ISO 11452 등 준수
• 고도 변화, 주행 속도, 운전자 반응성 등

이 환경 조건을 무시하고 HARA를 작성하면?
→ 잘못된 ASIL 도출 → 과잉 또는 과소 설계 → 비용 폭탄 or 안전 미달

✅ 팁: “해당 조건에서 실제 이 고장이 일어났을 때 위험한가?”를 항상 질문하세요!

4️⃣ S-E-C 평가 및 ASIL 결정

→ 위 예시의 경우, 매트릭스를 통해 ASIL D로 평가될 수 있음

🧰 3. 실무에서 유용한 팁 3가지

🧠 1) 안전팀 + 개발팀 협업은 필수!

• 안전팀만으로 HARA 돌리면 현실성 떨어짐
• 개발자는 시스템 이해도 높음 → 반드시 함께 참여해야 정확한 평가 가능

🗂️ 2) HARA 문서, 관리 툴과 연결하자!

• DOORS, Polarion, Excel 등 추적 가능한 툴을 사용하면
  이후의 Safety Goal, Requirements까지 관리가 수월해져요.

🧪 3) 유사 시스템의 사례 참고 (단, 출처는 명확히!)

• ISO 26262 인증 받은 시스템의 공개 사례 (예: AUTOSAR Consortium 자료 등)
• 학술 논문, 산업 컨퍼런스 자료, OEM 요구사항 문서 등 활용

출처가 명확하지 않다면? 그냥 쓰지 마세요!
실무에서 가장 무서운 건 “근거 없는 안전”입니다.

🏁 오늘의 정리

• HARA는 “위험 시나리오 → 평가 → ASIL 부여”의 논리적 절차
• 환경 조건을 반영하지 않으면 실효성 없는 분석이 된다
• 개발자와 협업하고, 추적 가능한 방식으로 문서화해야 함

🔮 다음 강 예고

다음 시간엔 위험이 정리됐으니, 이제 어떻게 목표를 세우고 설계할지 고민해봅시다!

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

• 실전 예시
• 설계 반영 방법
• 리뷰 체크리스트까지!

기대 많이 해주세요! 🎯🛡️

📘 11강. Item 정의서 작성 실전 – 개발 전에 무엇을 정의해야 할까?

안녕하세요, 기능안전 마스터를 향해 한걸음씩 나아가고 있는 여러분!
이번 시간에는 기능안전의 첫 단추, 바로 Item 정의서(Item Definition)를
어떻게 작성해야 하는지 실전적으로 알려드립니다.
“Item 정의? 이름만 알겠고 어떻게 쓰는지 감이 안 와요!”
라고 하신다면, 오늘 완전 정복 가능합니다! 💪

🧭 1. Item 정의란 무엇인가?

Item 정의는 ‘우리가 안전하게 만들고 싶은 기능’을 정확히 문서화하는 단계입니다.
ISO 26262 Part 3에서 정의하고 있으며,
이 정의서가 제대로 작성돼야 HARA(위험 분석)도, ASIL 결정도 가능해집니다!

한 마디로 말해, “뭘 만들 건지, 언제, 어디서, 어떻게 쓰일 건지”
를 정리한 개발의 나침반이자 설계의 출발점입니다. 🧭

🛠️ 2. Item 정의서 기본 구조

아래는 ISO 26262의 대표적인 구성 가이드를 기반으로 한 Item 정의서의 기본 항목입니다.
(출처: ISO 26262-3:2018, Clause 5.4 – Item definition requirements)

✍️ 3. Item 정의서 작성 예시 (실전 버전)

✅ 예시: 전자식 파킹 브레이크 시스템 (EPB)

이런 식으로 구체적으로, 명확하게, 실사용 조건을 기준으로 작성하는 것이 핵심입니다!

💡 실무 꿀팁

• ✔ 시스템 엔지니어, 기획자, 소프트웨어 개발자와 협업 필수
• ✔ ISO 26262 요구사항을 반영한 Item 정의서 템플릿 활용 권장
• ✔ 품질팀·기능안전팀에서 리뷰 필수 – 왜? 이 문서로 HARA·ASIL 결정이 이뤄지기 때문!

🏁 오늘의 정리

• Item 정의서는 ISO 26262 기능안전의 출발점
• 시스템 범위, 기능, 인터페이스, 제약조건 등을 명확히 기술해야 함
• 정확한 출처 기반 + 협업 중심 + 표준 구조 활용이 성공의 열쇠!

🔮 다음 강 예고

이제 Item 정의서까지 완성됐으니,
본격적으로 위험을 파헤칠 차례!

12강: HARA(위험 분석 및 위험성 평가) – 실무 팁과 예시 대방출!

• HARA 작성법
• 위험 시나리오 도출 방법
• S-E-C 평가 팁까지!

궁금하시죠? 곧 찾아뵐게요! 🧨📝

🎯 10강. ASIL이 뭐길래? – Automotive Safety Integrity Level 완전 정복

안녕하세요, 기능안전 스카우트 여러분! 🕵️‍♂️
오늘은 ISO 26262의 핵심 중의 핵심인 ASIL(Automotive Safety Integrity Level) 을 파헤쳐 봅니다.
“D가 제일 무섭다는데… 왜죠?” “OEM이랑 Tier 1은 뭘 더 해야 하죠?”
모~든 궁금증, 여기서 싹 풀어드릴게요!

🚦 1. ASIL 계산의 3요소 – S·E·C가 뭐야?

세 숫자를 매트릭스에 넣으면 ASIL D > C > B > A > QM(Quality Management) 순으로 등급이 튀어 나옵니다.

고·위·험 = ASIL D,
낮·은·위험 = QM (“그냥 품질 관리만 해도 됨” 수준)

🚘 2. 레벨별 실전 예시

Tip! ASIL은 사람 목숨과 직결될수록 높다고 외우면 끝!

🏢 3. ASIL이 OEM·Tier 1에 미치는 파급력

✨ OEM(완성차) 관점

• 조달 요구사항: “ASIL C 이상만 받아요.”
• 승인 게이트: DFMEA·FMEDA·Safety Case 안 갖추면 출구 없음 🚫
• 필수 감사: 독립 평가자(ISA) 투입, 서류+테스트 콤보 검증

🔧 Tier 1(시스템 공급사) 관점

ASIL D 프로젝트면 테스트/문서 인력만 들어도 비용 40 %↑
하지만 OEM과 계약하려면 피할 수 없다!

📚 4. 실무 포인트 – 레벨 따라 전략이 달라진다!

1. 초기 견적 단계
   • ASIL C · D라면 안전 예산 별도로 잡기
2. 계약서
   • “ASIL X 달성 책임 = Tier 1” 조항 체크!
3. 개발 일정
   • ASIL 높을수록 검증 게이트를 촘촘히
4. 공정·운영·폐기
   • 앞선 9강 내용처럼, ASIL이 높으면 전 생애주기 강화 🏭

🏁 오늘 핵심 정리

• ASIL = S·E·C 매트릭스가 뱉어내는 위험 등급 레벨
• D가 최고 위험, QM은 그냥 품질 관리
• OEM: 공급사에 높은 ASIL 요구 → 브랜드 보호
• Tier 1: ASIL 올라갈수록 문서·테스트·비용 수직 상승
• 전략은 “초기부터 ASIL 명확+코스트/리소스 계획”이 답!

🔮 다음 시간 예고

“이제 아이템 정의서 좀 써봅시다!”
개발 시작 전에 ‘우리가 만드는 게 정확히 뭔지’ 못 박는 단계!

11강: Item 정의서 작성 실전 – 개발 전에 무엇을 정의해야 할까?
템플릿부터 작성 팁까지 실전 편으로 찾아올게요. 📝🚀