오늘은 시스템 안전성과 보안성 검증에서 핵심적인 역할을 하는
GSN(Goal Structuring Notation)에 대해 이야기해보려 합니다.
GSN은 초보자도 쉽게 이해할 수 있는 구조적 언어로,
복잡한 시스템의 주장과 논리를 명확히 표현하는 데 사용됩니다.
이번 포스팅을 통해 GSN의 기본 개념, 구조, 그리고 실제 활용 사례를 살펴보겠습니다.
<< 기능안전 (ISO 26262) 관련 포스팅 전체 보기
GSN - 안전케이스(Safety Case) 관련 포스팅
- GSN(Goal Structuring Notation) - 안전 케이스(Safety Case, ISO 26262), 보안 케이스(Security Case, ISO 21434)
- GSN(Goal Structuring Notation) 표기법 - 안전케이스(Safety Case)/보안케이스(Security Case) 작성
- GSN(Goal Structuring Notation) 해석 - 안전케이스(Safety Case) 작성 규칙
1. GSN(Goal Structuring Notation)이란 무엇인가?
GSN은 논리를 시각적으로 표현할 수 있는 그래픽 기반의 표기법입니다. 이를 통해 주장(claims)과 이를 뒷받침하는 근거(evidence)를 체계적으로 연결할 수 있습니다.
GSN은 1990년대 초반, 영국의 요크 대학교(University of York)에서 진행된 ASAM-II 프로젝트(Advances in Safety Argument Management)에서 처음 개발되었습니다. 이 프로젝트는 복잡한 시스템의 안전성을 체계적으로 입증하기 위한 논증 도구를 개발하는 것을 목표로 했습니다.
영향받은 이론과 방법론
1. Toulmin의 논증 모델(Toulmin Argument Model):
- 철학자 스티븐 툴민(Stephen Toulmin)이 제시한 논증 구조 모델이 GSN의 주요 개념에 큰 영향을 미쳤습니다.
- 주장, 근거, 보증(warrant), 반박 가능성 등을 구조화하여 논증을 설득력 있게 표현하는 방식이 GSN의 기초로 활용되었습니다.
2. 요구사항 공학의 KAOS 모델:
- KAOS(Keep All Objectives Satisfied)는 목표 기반 요구사항 공학 방법론으로, GSN의 목표 설정 및 논증 패턴 설계에 영향을 주었습니다.
GSN의 표준화
GSN은 개발 이후 계속 발전을 거듭하며, 다양한 산업에서 활용 가능한 표준으로 자리 잡았습니다. 2018년에는 SCSC(Safety Critical Systems Club)가 GSN Community Standard의 Version 2를 발표하며, GSN의 요소와 구조, 확장 가능성을 체계적으로 정의했습니다.
현재 GSN은 안전성 및 신뢰성이 중요한 시스템(예: 항공, 자동차, 에너지, 의료 등)에서 널리 사용되며, 다양한 산업 규정(예: ISO 26262, DO-178C)과 연계하여 활용되고 있습니다.
주요 특징은 다음과 같습니다:
- Goals: 검증하고자 하는 주요 명제.
- Solutions: 주장을 뒷받침하는 구체적인 증거.
- Strategies: 상위 주장을 하위 주장으로 세분화하는 논리적 방법.
- Contexts: 논리의 전제가 되는 환경이나 조건.
- Assumptions: 논리를 성립시키기 위한 전제 조건.
- Justifications: 특정 전략이나 주장을 사용하는 이유를 설명.
2. GSN이 중요한 이유
GSN은 복잡한 시스템에서 안전성(Safety)이나 보안(Security)을 입증하기 위해 사용됩니다. 특히 Assurance Case(보증 사례) 또는 안전 케이스나 보안 케이스를 작성할 때 GSN은 다음과 같은 이점을 제공합니다:
- 명확한 의사소통: 개발자, 인증 기관, 이해관계자 간의 논리와 증거를 쉽게 공유할 수 있습니다.
- 효율적인 검토 과정: 체계적 구조 덕분에 논리적 오류를 쉽게 식별하고 수정할 수 있습니다.
- 문서화 표준 제공: GSN은 체계적인 문서화 방식으로 지속적인 검증 및 유지관리가 가능합니다.
3. GSN의 핵심 구성 요소 - Goal (목표)
Goal의 의미
GSN(Goal Structuring Notation)에서 Goal은 논증의 중심이 되는 핵심 주장을 나타내며, GSN 구조의 모든 논리적 흐름과 관계가 이 Goal을 중심으로 구성됩니다. Goal은 시스템, 서비스, 또는 프로세스가 특정 요구 사항을 충족하거나, 주어진 환경에서 올바르게 작동함을 입증하는 역할을 합니다. 즉, Goal은 "무엇을 증명하고자 하는가?"에 해당합니다. 예를 들어:
G1: “시스템 X는 단일 구성 요소 고장을 견딜 수 있다. (System X can tolerate single component failures.)”
Goal의 역할
1. 논증의 핵심 주장 표현
- Goal은 논증에서 증명하고자 하는 중심 개념을 정의합니다.
- 모든 GSN 요소는 Goal과 직간접적으로 연결되어 논리적 근거를 제공합니다.
2. 상위-하위 구조 연결
- Goal은 상위 주장을 하위 주장(Sub-goals)으로 나눠 체계적으로 논리를 전개합니다.
- 각 하위 Goal은 상위 Goal을 뒷받침하며, 논증의 깊이를 확장합니다.
3. 증거와의 연결
- Goal은 Solution(증거)를 통해 뒷받침됩니다.
- 이를 통해 주장의 신뢰성을 입증할 수 있습니다.
GSN (Goal Structuring Notation) 표기법 바로 가기 >>
4. GSN의 핵심 구성 요소 - Solution (해결책)
Solutions의 의미
GSN(Goal Structuring Notation)에서 Solution은 논증의 핵심 주장(Goal)을 뒷받침하는 증거를 나타내는 구성 요소입니다. Solution은 논증의 신뢰성을 보장하는 중요한 역할을 하며, 구체적인 데이터를 제공함으로써 Goal의 타당성을 입증합니다.
Solution은 GSN에서 논증의 주장(Goal)을 뒷받침하기 위해 사용되는 구체적인 증거나 참조 자료를 나타냅니다. 즉, 주장을 뒷받침하기 위한 증거를 제시합니다. 예를 들어:
Sn1: “위험 H1에 대한 결함 트리 분석. (Fault Tree for Hazard H1)"
Solution의 역할
1. 증거 제공
- Solution은 Goal이 주장하는 내용을 입증하기 위한 구체적이고 검증 가능한 데이터를 제공합니다.
- 예: “System X tolerates single-point failures”라는 Goal에 대해 “Stress Test Report”를 Solution으로 제시.
2. 논리적 연결
- Solution은 Goal과 직접적으로 연결되며, 논증 구조 내에서 증거의 흐름을 명확히 합니다.
- SupportedBy 관계를 통해 Goal과 연결됩니다.
3. 신뢰성 강화
- Goal에 대한 증거를 명확히 제시함으로써 논증의 신뢰성과 설득력을 강화합니다.
Solution의 유형
유형 | 설명 |
테스트 결과 | • 시스템이 특정 요구를 충족한다는 것을 입증하기 위해 사용. • 예: “Brake Response Time Test Results.” |
분석 보고서 | • 위험 분석, 결함 트리 분석(FTA), 고장 모드 영향 분석(FMEA) 등을 포함. • 예: “Hazard Analysis for Subsystem A.” |
공식 문서 | • 표준 또는 인증 문서. • 예: “Compliance with ISO 26262 Standards.” |
실험 데이터 | • 실험 결과를 통해 주장을 검증. • 예: “Sensor Calibration Data.” |
GSN (Goal Structuring Notation) 표기법 바로 가기 >>
5. GSN의 핵심 구성 요소 - Strategies (전략)
Strategy의 의미
GSN(Goal Structuring Notation)에서 Strategy(전략)는 상위 목표(Goal)를 하위 주장(Sub-goals)으로 세분화하여 논증의 구조를 체계적으로 전개하는 중요한 구성 요소입니다.
Strategy는 논증의 추론 과정을 설명하며, 상위 Goal과 하위 Goal 간의 논리적 연결을 명확히 합니다.
Strategy는 Goal 간의 관계를 설명하며, 상위 Goal을 뒷받침하기 위해 어떤 방식으로 하위 Goal을 구성할 것인지를 나타냅니다. 즉, 상위 주장을 하위 주장으로 나누는 논리적 단계를 설명합니다.
S1: “모든 해저드 제거를 주장할 수 있는 논증. (Argument by appeal to elimination of all hazards.)”
Strategy의 역할
1. 상위 Goal을 하위 Goal로 분할
- Strategy는 상위 Goal의 주장을 세분화하여 구체화합니다.
- 하위 Goal은 상위 Goal을 논리적으로 뒷받침합니다.
2. 논리적 연결 설명
- Strategy는 상위 Goal과 하위 Goal 간의 추론 관계를 설명합니다.
- 논증의 전개 방식을 이해하기 쉽게 만듭니다.
3. 효율적인 논증 구조화
- 복잡한 논증 구조를 논리적 단계로 나눔으로써 체계적인 논증 전개를 지원합니다.
Strategy의 유형
유형 | 설명 |
위험 기반 논증 | • 모든 위험을 식별하고 제거하거나 완화하는 접근 방식. • 예: “Argument by elimination of all hazards.” |
구성 요소 기반 논증 | • 시스템을 구성 요소로 나누어 각각의 안전성을 논증. • 예: “Argument by division into components.” |
표준 기반 논증 | • 표준이나 규정을 기반으로 안전성을 입증. • 예: “Argument by compliance with ISO 26262.” |
기능 기반 논증 | • 시스템의 주요 기능별로 안전성을 입증. • 예: “Argument over primary system functions.” |
GSN (Goal Structuring Notation) 표기법 바로 가기 >>
6. GSN의 핵심 구성 요소 - Context (문맥)
Contexts의 의미
GSN(Goal Structuring Notation)에서 Context(문맥)는 특정 논증의 주장이 적용되는 전제 조건, 환경, 범위 또는 추가적인 정보를 제공하는 요소를 의미합니다. Context는 Goal이나 Strategy를 이해하는 데 필요한 배경 정보를 제공하며, 논증의 의미를 명확히 하고 논리적 오류를 방지하는 데 중요한 역할을 합니다. Context는 논증의 배경 정보를 설명하거나 주장이 적용되는 조건과 환경을 명시합니다. 즉, 논리나 주장이 적용되는 환경을 명확히 합니다.
C1: “식별된 모든 시스템 해저드. (All identified system hazards)”
Context의 역할
1. 추가 정보 제공
- Goal이나 Strategy가 제대로 이해되기 위해 필요한 배경 정보를 제공합니다.
- 예: “Operating environment defined as normal and extreme conditions.”
2. 논증의 범위 설정
- 논증이 적용되는 범위와 조건을 명확히 하여 불필요한 혼란을 방지합니다.
- 예: “Applicable to system operations during peak traffic hours.”
3. 논리적 일관성 유지
- Goal이나 Strategy가 문맥 내에서 논리적으로 일관되도록 보장합니다.
- 예: “All hazards identified using standard HAZOP methodology.”
4. 가정이나 제약 조건의 명시
- 논증이 의존하는 가정 또는 제약 조건을 명확히 기술합니다.
- 예: “System operates in environments with temperatures between -20°C and 50°C.”
Context의 유형
유형 | 설명 |
환경 정의 | • 시스템이 작동하는 물리적, 논리적 환경을 명시합니다. • 예: “System operates in urban traffic conditions.” |
범위 설정 | • 논증이 적용되는 범위나 조건을 설정합니다. • 예: “Applicable to Version 2.0 of the software.” |
기준 문서 참조 | • 표준, 가이드라인 또는 관련 문서를 참조합니다. • 예: “Compliant with ISO 26262.” |
관련 데이터 | • 논증과 관련된 데이터를 제공합니다. • 예: “Sensor calibration data included.” |
GSN (Goal Structuring Notation) 표기법 바로 가기 >>
7. GSN의 핵심 구성 요소 - Assumption (가정)
Assumption의 의미
GSN(Goal Structuring Notation)에서 Assumption(가정)은 논증이 성립하기 위해 참이라고 간주하는 전제 조건을 나타냅니다.
Assumption은 검증되지 않았거나 검증할 필요가 없는 요소를 의미하며, 논증의 논리적 흐름을 전개하는 데 중요한 역할을 합니다.
Assumption은 논증이 성립하기 위해 반드시 참이어야 하는 조건이나 전제를 명시합니다. 즉, 논리를 성립시키는 전제 조건입니다.
A1: “모든 신뢰할 수 있는 위험이 정확히 식별되었다.”
전략(Strategy_S1)은 가정(Assumption_A1)을 전제로 수립되었습니다.
※ GSN에서 사용된 연결(Connect)은 별도로 정리 하겠습니다.
Assumption의 역할
1. 논증의 전제 조건 명시
- 논증이 성립하기 위해 필요한 기본 조건을 명확히 제시합니다.
- 예: “모든 잠재적 위험이 정확히 식별되었다.”
2. 논증 범위 제한
- Assumption은 논증의 적용 범위를 제한하여 불필요한 복잡성을 줄입니다.
- 예: “이 논증은 정상 작동 환경에서만 적용된다.”
3. 논증의 명확성 보장
- 가정을 명시적으로 기술하여 논증을 검토하거나 평가할 때 혼란을 방지합니다.
Assumption의 유형
유형 | 설명 |
환경 기반 가정 | • 논증이 특정 환경에서만 성립함을 가정. • 예: “System operates within the specified temperature range.” |
사용자 행동 가정 | • 시스템 사용자가 규정을 준수한다고 가정. • 예: “All operators are trained and certified.” |
완전성 가정 | • 특정 프로세스가 완전하게 수행되었음을 가정. • 예: “All credible hazards have been identified.” |
외부 조건 가정 | • 시스템 외부의 특정 조건이 변하지 않음을 가정. • 예: “Power supply remains stable during operation.” |
정당화(Justifications) | 특정 전략이나 주장을 채택한 이유를 제공합니다. J1: “도메인 표준 123이 SIL 할당 접근법을 허용함.” |
GSN (Goal Structuring Notation) 표기법 바로 가기 >>
8. GSN의 핵심 구성 요소 - Justification (정당화)
GSN(Goal Structuring Notation)에서 Justification(정당화)는 특정 논증이나 접근 방식을 선택한 이유를 설명하는 구성 요소입니다. Justification은 논증의 타당성을 강화하고, Goal 또는 Strategy에 대한 의문이나 도전에 답변하기 위한 근거를 제공합니다. Justification은 논증의 특정 주장이 왜 적절한지, 또는 선택한 접근 방식이 왜 적합한지를 명시적으로 설명합니다. 즉, 특정 전략이나 주장을 채택한 이유를 제공합니다.
J1: “도메인 표준 123이 SIL 할당 접근법을 허용함.”
Justification의 역할
1. 논증의 타당성 보강
- 논증 구조 내에서 특정 주장이 왜 적절한지에 대한 근거를 제시합니다.
- 예: “SIL(Safety Integrity Level) 분할이 도메인 표준에 따라 수행됨.”
2. 의문과 도전 대응
- Goal 또는 Strategy에 대해 제기될 수 있는 의문이나 도전에 대응할 논리적 근거를 제공합니다.
- 예: “이 논증 방식이 채택된 이유는 안전성 표준을 준수하기 때문.”
3. 논증 구조의 명확성 향상
- 논증의 배경 논리를 명시적으로 표현하여 이해관계자의 이해를 돕습니다.
GSN (Goal Structuring Notation) 표기법 바로 가기 >>
9. GSN 구조의 예 (설명 포함)
아래는 GSN 구조의 간단한 예입니다:
- Goal_G1: "제어 시스템은 수용가능한 수준의 안전을 확보하고 있음"
- Context_C1: G1을 달성하기 위해서는 "해당 제어 시스템에 대한 역할과 기능이 제시됨"
- Context_C2: G1을 달성함에 있어 "해당 시스템이 정의됨"
- Goal_G1 → Goal_G2/Goal_G3: G1을 달성하기 위해 분석 관점(G2)과 개발 관점(G3)로 주장을 세분화 하였습니다.
- Goal_G2: "모든 식별가능한 해저드들이 제거되었거나 충분히 경감"
- Context_C3: G2에서 정의한 충분성을 측정하기 위해 "허용 수준이 제시됨"
- Strategy_S1: G2에 대한 근거를 제시하기 위해 "식별된 해저드에 대한 근거를 제시함"
- Strategy_S1 → Goal_G4/Goal_G5/Goal_G6: S1을 뒷받침하기 위해 새로운 주장(G4/G5/G6)을 추가로 정의 하였습니다.
- Assumption_A1: 식별된 해저드 근거를 제시하기 위한 가정은 "모든 해저드가 식별됨"
- Goal_G4: "첫번째 해저드(H1)가 제거됨"
- Solution_Sn1: "정형 검증으로 첫번째 해저드(H1)가 제거되었음을 보임"
- Goal_G5: "두번째 해저드(H2)가 수용 가능한 수준으로 고장율(< 1x10^-6 per year)이 확보됨"
- Goal_G6: "세번째 해저드(H3)가 수용 가능한 수준으로 고장율(< 1x10^-3 per year)이 확보됨"
- Solution_Sn2: "Fault Tree Analysis(FTA)로 두번째 해저드(H2)와 세번째 해저드(H3)가 충분히 수용가능한 수준으로 고장율이 낮음을 보임"
- Goal_G3: "제어 시스템에서 소프트웨어는 발생가능한 해저드에 대해 적절한 안전 무결성(SIL)을 고려하여 개발됨"
- Context_C4: G2와 G3에서 발생가능한 해저드를 다루고 위해 "FHA 기법을 이용하여 해저드가 식별됨"
- Context_C5: G3를 달성하기 위해 "안전 무결성을 고려한 개발 가이드라인과 프로세스가 제시됨"
- Strategy_S2: G3에 대한 근거를 제시하기 위해 "첫번째, 두번째 엘리먼트에 할당된 안전 무결성이 적절함에 대한 근거를 제시함"
- Justification_J1: S2에서 제시된 근거를 통해 "할당된 안전 무결성이 확보 될 수 있음"
- Context_C6: 안전 무결성에 대한 적절한 근거 제시를 위해 "소프트웨어 해저드가 식별되어야 함"
- Strategy_S2 → Goal_G7/Goal_G8: S1을 뒷받침하기 위해 새로운 주장(G7/G8)을 추가로 정의 하였습니다.
- Goal_G7: "주요 보호 시스템은 SIL 4가 할당됨"
- Solution_Sn3: "SIL 4에 준하는 프로세스로 개발됨"
- Goal_G8: "부가 보호 시스템은 SIL 2가 할당됨"
- Solution_Sn4: "SIL 2에 준하는 프로세스로 개발됨"
10. GSN의 한계와 주의사항
- 진실 보증이 아님: GSN은 단지 논리를 문서화할 뿐, 주장의 진실 여부를 보장하지 않습니다.
- 복잡성 관리: 구조가 복잡해질수록 이해하기 어려울 수 있으므로 단순하게 유지하는 것이 중요합니다.
GSN은 안전성과 보안성을 입증하는 데 매우 유용한 도구입니다. 하지만 그것만으로 모든 문제를 해결할 수는 없으며, 올바른 증거와 신뢰할 수 있는 데이터를 함께 활용해야 합니다. 초보자라면 간단한 사례부터 시작하여 GSN의 기본 개념과 활용법을 익혀보세요. 😊
<< 기능안전 (ISO 26262) 관련 포스팅 전체 보기
GSN - 안전케이스(Safety Case) 관련 포스팅
- GSN(Goal Structuring Notation) - 안전 케이스(Safety Case, ISO 26262), 보안 케이스(Security Case, ISO 21434)
- GSN(Goal Structuring Notation) 표기법 - 안전케이스(Safety Case)/보안케이스(Security Case) 작성
- GSN(Goal Structuring Notation) 해석 - 안전케이스(Safety Case) 작성 규칙
'Automotive > ISO 26262 (기능안전)' 카테고리의 다른 글
GSN(Goal Structuring Notation) 해석 - 안전케이스(Safety Case) 작성 규칙 (0) | 2024.12.22 |
---|---|
GSN(Goal Structuring Notation) 표기법 - 안전케이스(Safety Case)/보안케이스(Security Case) 작성 (0) | 2024.12.22 |
ISO 26262의 Proven in Use: 의미, 목적 및 필요성 (3) | 2024.12.06 |
ISO 26262:2018, 자동차 기능안전 용어 (Part 1) : 용어의 중요성과 설명 (0) | 2024.09.19 |
ISO 26262: Vocabulary (Part 1), 기능안전 표준 용어 정리 (2018) - U ~ W (0) | 2024.09.19 |