SSARC 소프트웨어 안전성 보증 연구센터

안전성 분석

소프트웨어로 인한 사고를 사전에 미리 예방하기 위한 소프트웨어 안전성 분석 기법 및 프로세스 개발/활용 방안 연구

사고 원인 모델(Accident Causality Model)

사고 예방을 위한 효과적인 방법을 개발하기 위해서는 어떠한 요인이 사고를 야기하는지를 우선적으로 파악해야 한다. 사고 분석가들은 사고 원인 파악 및 예측을 위하여 사고 발생 시나리오 및 원인에 대한 개념모델인 사고 원인 모델을 형성한다. 효과적인 사고 분석을 위해서는 적합한 사고 원인 모델을 형성하는 것이 중요하다. 사고 원인 모델으로 많이 활용되는 모델은 다음과 같다.


① Chain of Event 모델
- 구성 요소들의 연속적인 실패 사건(Failure Event)들로 인해 사고가 발생한다는 이론에 기반한 사고 원인 모델
- 연속적인 실패 사건의 일부를 제거함으로써 사고를 예방함

② STAMP(System Theoretic Accident Model and Process)
- 시스템 이론(System Theory)에 기반한 사고 원인 모델
- 시스템 요구사항에 사고 발생을 예방하기 위해 준수해야할 제약사항을 부과하여 안전성을 확보하는데 목적을 둔 모델

Hazard 분석(Hazard Analysis)

Hazard 분석은 Hazardous 상황을 미리 예측하여 미연의 사고 발생을 예방하기 위한 방법이다. 사고에 이르게 되는 Hazard를 식별하고 식별된 Hazard를 평가하며, Hazard 발생 원인과 시나리오 분석을 수행함으로써 사고가 발생하기 전 시스템 안전성 확보를 위한 대책을 수립한다.


① Chain of Event 모델에 기반한 Hazard 분석 방법
- 시스템 컴포넌트의 실패를 Hazard로 보는 신뢰성 이론에 기반을 두는 Hazard 분석 방법
- FTA(Fault Tree Analysis), FMEA(Failure Mode Effects Analysis), HAZOP(Hazard and Operability Studies) 등

② STAMP의 Hazard 분석 방법 : STPA(System Process Analysis)
- 가이드 단어(Guide word)를 통해 각 컴포넌트들 간의 상호작용에서 발생하는 불완전한 제어 명령(Unsafe Control Action)을 파악하여 Hazard를 분석

STPA의 가이드 단어 불안전한 제어 명령 유형
Notproviding 수행되어야 하는 제어 명령이 이루어지지 않음
Providing Causes 부정확하거나 불안전한 제어 명령이 수행됨
(Provide)
Toolate or Too Early
제어 명령이 수행되어야 할 시전보다 이르거나 늦게 수행됨
(Stopped)Too Soon or
(Applied)Too long
제어 명령이 예정 기간보다 빨리 멈추거나, 늦게까지 지속됨
[불안전한 제어 명령 유형에 대응되는 STPA가이드 단어]

기존의 Hazard 분석 방법들은 Hazard 식별 단계에서 가이드 단어를 통해서만 Hazard를 식별한다. 따라서 대상 시스템에 대한 분석가의 전문성에 따라 많은 차이를 보일 수 있다. 이러한 점을 해결하기 위해 본 센터에서는 아래와 같은 연구를 진행하였다.



CTT 기반의 STPA를 활용한 Hazard 분석 프로세스

체계적인 Hazard 식별을 위한 사전 작업으로 태스크 분석 방법이자 표기법인 CTT를 활용한 태스크 분석 및 명세방법을 추가하여 기존의 STPA보다 체계적인 프로세스를 제안한다.


[CTT기반의 STPA를 활용한 Hazard 분석 프로세스]


① 요구사항 식별
- Usecase Diagram을 활용하여 대상 시스템의 요구사항 식별
- 대상시스템의 시스템 구성도를 파악하기 위한 제어 구조도(Control Structure) 작성

② 태스크 분석 및 명세
- 대상 시스템의 태스크를 분석하고, CTT를 활용하여 태스크 간의 관계를 명세

③ Hazard 식별
- CTT기반의 STPA 가이드단어 맵핑 테이블을 활용하여 Hazard 식별



[CTT기반의 STPA 가이드 단어 맵핑 테이블 예시]


④ 안전성 요구사항 작성
- 평가한 Hazard에 대한 안전성 제약사항(Safety Requirement) 작성

안전성 보증 프로세스

안전성 요구사항을 만족할 수 있는 소프트웨어 설계 및 소스코드 기반 구조 확립

소프트웨어 안전성 확보를 위한 설계

소프트웨어 아키텍처 설계가 안전성을 고려하였다면 소프트웨어의 품질 요소, 즉 수정용이성, 가용성, 테스트 용이성, 신뢰성을 확보하기가 보다 수월하다. 특히, 임베디드 소프트웨어 개발에 적용할 수 있는 설계 기법인 Layered Architecture, 임베디드 SOLID, 의존성 제약 등의 적용이 필요하며, 개발 과정 중 설계 기법 준수 여부의 확인이 필요하다.


소프트웨어 안전성 확보를 위한 소스코드 기본 품질 확보

소스코드의 안전성 확보를 하기에 앞서 소스코드 자체의 기본 품질 확보가 우선이다.
    ■ 소스코드 기본 품질을 확보하지 못하면 안전성 요구사항을 만족하기 어려움
        - 소스코드 복잡도가 높으면 테스트 커버리지를 만족하기 어려움
        - 소스코드 복잡도가 높고 의존성이 높으면 소스코드를 수정하기 어려움
        - 소스코드 중복이 많으면 비가시적인 결합도가 높아짐
        - 헤더파일 의존관계를 관리하지 않으면 결합도가 높아지며, 소스코드 분석이 어려움

소프트웨어 안전성 표준 역시 소스코드와 관련한 요구사항을 제시하고 있다.
    ■ 소스코드 관련 안전성 요구사항 (ISO 26262)
        - MISRA C 코딩 표준 만족
        - 테스트 커버리지 만족(Line, Branch, MC/DC)
        - 높은 응집도, 낮은 결합도
        - 적절한 컴포넌트 크기
        - 흐름 분석
소스코드의 기본 품질을 확보 및 안전성 요구사항을 만족하기 위해서는 소스코드 품질 기준 수립 및 리팩토링(Refactoring) 기법 적용으로 소스코드 품질과 개발 역량을 향상해야 한다.

소프트웨어 Visualization과의 연계 방안

설계 및 소스코드 품질을 확보하기 위해서는 설계 및 구현 단계에서 소스코드가 설계 및 품질 기준을 만족하는지 지속적으로 확인하고, 문제 발생 시 개발자 통보로 발생 초기 해결하는 활동이 필요하다. 이는 소프트웨어 Visualization과의 연계를 통해 구현이 가능하다.


기대 효과

① 스코드 품질 확보(수정 용이성, 가용성, 이식성 등)
② SW 기능 안전 표준의 소스코드 기준 만족
③ 레거시 코드의 품질 개선
④ 소프트웨어 개발자 코딩 역량 향상

안전성 Gate : 안전성 감사 활동

품질 Gate(Quality Gate) 설치를 통해 소프트웨어 품질 상태와 안전성 요구사항 준수 여부를 개발단계 전체에 걸쳐 확인

소프트웨어 개발 단계별 안전성 점검 체크리스트를 통한 능력 수준 평가 모델

안전한 소프트웨어를 개발하기 위해서는 각 단계마다 일정 수준의 품질 보장 활동을 수행해야 한다. 품질 보장 활동들은 프로세스의 준수 여부와 제품의 완전성 여부를 점검하는 방식으로 이루어진다. 관리자의 입장에서는 각 단계별로 일정 수준의 품질을 보장하는 작업이 필요하기 때문에 SGM (Software Gate Model)을 활용하여 단계별 점검을 강화할 필요가 있다. 또한, 조직 혹은 프로젝트 마다 특성이 다르기 떄문에 각 프로젝트의 특성에 맞는 품질 Gate의 설정이 필요하고, 각 Gate별로 적합한 체크리스트를 도출하는 작업이 요구된다.


이를 위해서는 크게 3가지 작업이 필요하다.

① 안전성 보증 통합 모델 개발
    - CMMI와 A-SPICE 모델 등의 국제 표준모델 혹은 업계표준을 참조모델로 선정하여 안전성 보증 활동 분석 및 통합
    - 일반화된 안전성 보증 체크리스트와 조직표준과의 호환성을 확보하여 개발하는 것이 중요함

② 안전성 Gate 설정
    - ISO 12207 및 전사 프로세스를 기반으로 소프트웨어 개발 생명주기의 단계에 따른 안전성 Gate 설정 및 각 단계별 수행 정의

③ Gate별 안전성 보증 체크리스트 개발
    - 안전성 보증 통합 모델과 안전성 Gate를 통합하여 Gate별 안전성 보증 체크리스트 개발
    - 체크리스트 항목을 얼마나 구체적으로 작성했는지에 따라 점검의 효과가 달라지므로, 충분한 점검을 지원하도록 체크리스트를 작성하는 것이 중요함


[소프트웨어 개발 단계별 안전성 점검 체크리스트]

④ 각 평가항목 별 판단 기준 개발
    - 각 평가항목을 정량적으로 측정할 수 있는 평가 기준을 개발하여 평가 결과를 점수화

기대 효과

① 프로젝트 관리자가 효과적으로 소프트웨어 안전성 준수 여부 점검 가능
② 각 단계, 영역별로 소프트웨어 수행 능력/안전성 평가 가능
③ 소프트웨어 개발 체계 등급 (소프트웨어 수행 능력 수준) 개발 가능
    - 소프트웨어 개발 체계 등급 : 영역별 활동과 산출물의 우수한 정도를 등급으로 나타낸 것

SW Visualization : 안전성 지원 도구 및 활동

요구사항과 소스코드 추적, 소스코드 문제점 조기 발견, 빌드 가상화로 소스코드 안전성 확보를 위한 기반 구조를 구축

개발 초기부터 소프트웨어의 품질 수준 가시화

소프트웨어의 결함이나 빌드 실패, 높은 복잡도 등의 문제는 발견 즉시 해결하면 적은 비용으로 수정할 수 있지만, 개발 후반기에 발견할수록 많은 비용이 필요하다. 이는 결함, 순환 복잡도, 의존성, 결합도 등의 안전성 요소도 마찬가지이다. 소프트웨어 Visualization은 다음의 항목을 개발 초기에 가시화하여 소스코드의 품질 수준을 향상시킨다.
    - 개발 진행 상태
    - 소스코드 복잡도
    - 소스코드 의존성
    - 자동화 테스트 결과
    - 정적 분석 결과
    - 통합 빌드 결과
    - 요구사항과 소스코드간 추적


높은 품질의 임베디드 소프트웨어 개발을 위한 Visualization

많은 소프트웨어 Visualization 가이드나 성공 사례는 Java나 웹 개발 분야에 한정되어 있다. 그 이유는 해당 업계가 소프트웨어 Visualization 및 오픈소스 도구를 적극적으로 받아들이고, 성과에 대한 공유에 대한 장벽이 낮기 때문이다. 그러나 임베디드 소프트웨어 개발에 오픈소스를 기반으로 소프트웨어 Visualization을 적용하고, 안전성 인증을 획득한 상용 도구와도 긴밀히 연동할 수 있다.


소프트웨어 기능 안전과의 관계

소프트웨어 Visualization을 구축하고 적용한다고 해서 안전성이 확보된 소프트웨어가 개발되는 것이 아니다. 그러나 소프트웨어 안전성 확보를 위해 ISO 26262 등의 국제 표준에서 요구하는 항목의 달성을 위해서는 소스코드 품질에 대한 관리가 개발 초기부터 필요하다.
안전성 표준에서 요구하는 낮은 커플링, 중복 코드 제한, 제한된 의존성 구축 및 높은 테스트 커버리지를 달성하기 위해서는 각 항목의 관리가 필요하고, 소프트웨어 Visualization을 통해 개발 초기부터 시각화하여 그 수준을 관리할 수 있다. 또한 SQA/QA와 안전성 담당자 및 소스코드를 개발하고 소스코드 단위의 테스트를 진행하는 개발자가 빨리 인지하고 기준에 따라 개발하도록 지원한다.

만약 Visualization을 적용하지 않는다면 소스코드의 문제점은 개발 후반부에 발견될 것이며, 조치가 단순히 소스코드의 변경이 아닌 구조 변경으로 인한 재설계/재구현/재테스트의 문제가 발생할 수 있다.
안전성 표준을 만족하기 위한 QAC, VectorCAST, CodeSonar, Polyspace 등의 도구는 소프트웨어 Visualization의 핵심 도구인 Jenkins와의 연동을 위한 도구나 자료를 제공하고 있다. 이를 활용하면 SQA/QA, 안전성 담당자, 개발자는 하루에 한 번 빌드 여부, MISRA C 준수 여부, 정적 분석을 자동으로 수행하고 결과를 확인할 수 있다.
또한 A-SPICE에서 요구하는 소프트웨어 Integration과 Regression Test는 소프트웨어 Visualization의 통합 빌드를 활용해 Practice를 달성할 수 있다.


임베디드 소프트웨어 빌드 환경을 30년 유지하기

임베디드 소프트웨어는 Java 개발과는 달리, 소스코드가 있어도 언제든지 빌드해서 출시 버전과 동일한 바이너리를 생성하기 어렵다. 컴파일러/버전, 운영체제/버전, 칩셋 제조사 라이브러리 등이 완전하게 유지되어야 한다.
그러나 개발자가 퇴사하거나, 빌드에 사용하던 PC의 고장 후 고객이 기능 개선 및 오류 조치를 요청하면 어떻게 해야 할까? 빌드 환경을 다시 구축하는데 오랜 시간이 걸릴 것이다. Windows XP에서 빌드하던 환경이라면, 지금 상황에서 그 환경을 다시 구축하기는 매우 어려울 것이다.

빌드 환경을 유지하기 위한 가장 좋은 방법은 빌드 환경을 가상화하여 소프트웨어로 유지하는 것이다. 가상화 기술은 보통 클라우드 서비스를 제공하는데 사용하지만, 임베디드 소프트웨어 개발의 빌드 환경을 유지하는 데도 이용할 수 있다.
소프트웨어 Visualization를 가상화 기술을 이용하여 확장하면 빌드 환경을 고장 없이 유지하여 고객의 요구에 기민하게 대처할 수 있다.


임베디드 소프트웨어 Visualization 구축 및 내재화 컨설팅 (단계적인 접근 제안)

소프트웨어 안전성 보증 연구센터(SSARC)는 임베디드 SW Visualization 전문가들의 연구 및 여러 적용 경험을 바탕으로, 다음과 같이 단계별 적용을 권고한다.

기대 효과

① 소프트웨어 품질 수준 조기 가시화 및 이상 항목 조치
② SW 기능 안전 표준 만족
③ 품질 측정 자동화
④ 소프트웨어 빌드 자동화 및 빌드 환경의 장기간 유지

안전성 Verification

소프트웨어 기능 안전성 요구사항이 포함된 소프트웨어를 체계적으로 검증하고 동일 문제의 재발을 예방하기 위한 체계 구축

소프트웨어 기능 안전성을 검증하기 위한 테스트 체계

기능 안전이 요구되는 소프트웨어는 이전 제품의 소스코드를 재활용 하여 시리즈로 개발하기도 하고, 동일 제품을 OEM이나 국가향에 따라 여러 버전으로 수정하기도 한다. 이러한 특징을 고려하면 다음과 같은 항목이 테스트 체계에 반영되어야 한다.
    - 안전성 요구사항 검증
    - 공통(Core) 부분과 개별(Variant) 부분의 테스트 방법
    - 기존 시리즈 문제점의 재발 방지
    - 자동화 가능 부분의 식별
    - 우선순위에 따른 테스트 수행
위와 같은 사항이 고려된 테스트 체계는 다음과 같이 구성된다.

정형 검증 기법의 적용

정형 검증은 소스코드의 수학적인 분석을 통해 소스코드의 이상 여부를 증명하는 방법이다. 안전성 보증 연구센터는 정형 검증 전문가로로부터 소프트웨어 Synthesis에 대해 다음과 같은 컨설팅을 받을 수 있다.
    - 주어진 명세가 실현 가능한지 검사
    - 실현 가능할 경우 명세를 만족하는 구현을 자동 생성
    - 안전성을 정확히 보장할 수 있는 모델 자동 생성
이를 통해 정형 명세부터 도구 적용을 통한 정형 검증 수행까지 안전성 표준에서 요구하는 일련의 정형 검증 기법 체계를 적용할 수 있다.

기대 효과

① 체계적인 소프트웨어 테스트 프로세스 구축
② 안전성 요구사항 만족 여부 검증
③ 기존 발생 결함의 재발 방지
④ 정형 검증을 통한 소스코드 검증 및 안전성 표준 만족

close

작성일: