카테고리 보관물: RAMS

(paper) Software 기반의 시스템에 대한 dependability 평가


흥미로운 논문이다. 2005년에 나온 논문으로 소프트웨어에 대한 안전성 평가의 허구성(?)과 불가능성(?)에 대해 다룬 논문이다.

A-SMGCS의 Validation방법을 조사하다가 찾은 논문인데, CNS/ATM분야 뿐만 아니라, 일반 산업분야에서도 적용이 가능할 것으로 생각한다.

내용을 간단하게 정리한다.

20년 전에: Flight control software에 대해 1.0E-09의 고장 확률에 대한 목표

  • 달성할 수 있겠는가? 측정할 수 있겠는가?

 

어떤 Reliability 수준이 요구되는가?

  • civil aircraft flight control: 1.0E-09/h의 고장확률
  • railway signaling control: 1.0E-12/h의 고장확률
  • UK의 원전 primary protection system: 1.0E-3/h의 고장확률

 

왜 불확실한가?

  • 소프트웨어의 고장(failure)은 systematic하다 – 만약 소프트웨어가 어떤 환경에서 고장나면 그 소프트웨어는 항상 그 환경에서 고장난다. (별표 10개, 밑줄 쫙쫙, 하이라이트 반짝반짝)
  • 그런데 문제는 H/W고장, Human factor, emergent property등과 같이 불확실한 환경이 발생해서 고장이 난다는 점
  • ‘Systematic’이 ‘deterministic’을 함축하는 것이 아님

 

Software의 unreliability를 이끄는 요인

소프트웨어가 완벽하게 동작하지 않는 이유가 무엇인가? 그것은 결국 로직이다.

왜 올바르게 돌아가지 않는거지?

  • 참신성: 급진적이로 새로운 기능을 구현하기 위해 소프트웨어가 사용된다.
  • 어려움: 소프트웨어 설계자가 풀어야 하는 문제들은 본질적으로 어렵다.
  • 복잡함: 이런 추세는 불필요하게 설계 솔루션의 복잡함을 유발함.

 

그래서 얼마나 심각한가?

만약 우리가 실제 프로그램을 결함이 없도록 만들 수 없다면, 얼마나 많은 결함을 예상할 수 있을까?

  • 달성할 수 있는 결함 밀도는 얼마일까?
    • C130J 소프트웨어의 연구사례에서 kLoC당 1.4 safety critical fault가 나왔다.
  • 여기에서는 좋은 소식은 없다.

 

얼마나 많은 결함이 매우 믿을 수 없는 것을 의미하는 것이지?

반드시 그런 것 만은 아님!

  • windows의 신뢰성은 windows 95/98의 300 hours MTBF에서부터 3000 hours로  증가해 왔음
  • 항공기 및 자동차의 소프트웨어에 대한 운영 경험(operational experience)는 높매우 높은 신뢰성이 달성 가능함을 제안함

 

어떻게 소프트웨어가 그렇게 신뢰성이 있을 수가 있지?

왜냐면 많은 결함들이 사소한 것이라서

 

그러면 뭐가 문제인데?

문제가 있어?

  • 크고 복잡한 프로그램이 매우 신뢰성이 있을 수 있기 때문에 특정한 한개가 그럴 수 있을거라는 것을 의미하는 게 아니야
    • 과거에 성공적으로 신뢰성 있는 소프트웨어를 만들었다고 해도 신규 프로그램이 신뢰성이 있다고 할 수는 없겠지
    • 과거에 소프트웨어 엔지니어링 프로세스가 성공적이라고 하더라도 다음에도 그렇게 될 거라고 할 수는 없겠지
  • 그래서 소프트웨어가 얼마나 믿을만한지를 측정하다는 것이 필요하다는 것
  • 그리고 이러한 평가는 광범위한 real-life operational use전에 수행되어야 할 필요가 있다
    • 그 외에 위험 평가를 할 수 있겠나?

그래서 어떻게 dependability를 평가할 수 있지?

응 ?

 

직접적 평가: 운영 시험

  • 운영 시험을 기반한 통계적 방법만이 신뢰도의 직접적 평가 수단이다.
    • MTBF, reliability function, failure rate의 estimation, prediction을 허용한다.
  • 이를 위해서는
    • 운영적 사용을 통계적으로 대표할 수 있는 테스트 데이터를 생성해야 함을 의미하지
    • 오류를 탐지할 수 있는 테스트 오라클이 필요하지
  • 수용 가능한/수용 불가능한 결과를 내는 절차가 reliability의 estimate 및 predict에 사용된다.

 

신뢰도 성장 모델링

25년간 많은 연구가 있었지

 

그래서 어떤 주장을 하고 싶은건데?

시험을 통한 reliability growth 은 매우 설득력이 약하다는 것이 밝혀졌다.

  • 예를 들어 MTBF로 x시간을 주장하고 싶다면 테스트에서 10~100 * x 정도의 시험 횟수가 필요하다
  • 더 나쁜 소식은, 여기에는 강력한 law of diminishing returns operating이 있다.
    • 매우 작은 결함을 찾으려고 한다면, 그것을 찾기가 굉장히 어렵겠지?

 

그래서 우리가 무엇을 할 수 있지?

가용한 다른 정보들이 많이 있기는 해

  • ex. software engineering process의 quality
  • ex. static analysis로부터의 정보
  • ex. expert judgement

Dependability ‘case’

비공식적으로, dependability case는 가정과 증거를 기반으로 한 argument이다.

그리고 이것은 어느정도 수준의 confidence에서의 dependability claim를 지원한다.

 

그런데, SE의 증거는 약해

소프트웨어 엔지니어링 프로세스는 product dependability claim을 지원하는 용도로 많이 사용되지

그런데, 그것은 매우 약해

process와 product간의 인과 관계를 보일 수 있는 몇몇 증거들이 있어(fault count)

그런데, process->product-> product reliability의 인과관계를 보일 수 있는 증거들은 없어(failure rate)

‘case’를 위한 뜨는 표기방식: BBNs

  • 장점
    • 추론에 강력한 도움
  • 단점
    • 과도한 낙관적 추정
    • 불확실성에 대한 확률을 표현하는데 인간은 어리숙하

 

결론

아직 해결되지 않았다. 연구가 필요하다.

 

 

 

Functional Safety에 대한 자격이 있는지를 검증하기


재미있는 논문을 봤다. 논문의 제목은 Understanding the Use, Misuse and Abuse of Safety Integrity Levels이다.

이 논문을 보니 functional safety에 대한 competency가 있는지를 확인하기 위한 질문들을 만들어낼 수 있을 것 같다.  functional safety관련 업무를 하는 사람들을 위한 일종의 자격시험이라고 봐도 무방할 듯..

  1. IEC61508에서 low demand operation의 SIL과 high demand operation의 SIL에서 failure rate의 차이에 대해서 왜 그렇게 정의되었는지 설명해보시오
  2. 다음의 표현이 적절한지에 대해서 생각해보고 그 의견을 말해보시오. “이 제품은 SIL3이고 표준에서 정의한 대로만 수행하면 SIL3(1.0E-08~1.0E-07)를 만족시킬 수 있어”
  3. 소프트웨어의 random fault는 어떻게 해결할 수 있지요?
  4. 소프트웨어의 function이 SIL에서 요구하는 failure rate에 부합하다는 것을 어떻게 입증할 수 있지요?
  5. failure rate에 대해 reliability 및 safety 측면에서 어떤 차이가 있을 수 있지요?
  6. 시스템에 부과된 SIL(ex; 1.0E-0.8~1.0E-07)을 만족(meet)시키려면 어떻게 해야 하나요?

….

 

 

 

 

 

소프트웨어 신뢰성


최근 소프트웨어 신뢰성 관련 자료를 찾아보고 있다. 소프트웨어에 신뢰성이란 말이 어울리지 않는다고 생각했고, 그래서 말도 안되는 소리라고 생각했었는데, 우연찮게 검색을하다가 발견했다.

생각보다 오래된 이론이더라는….

IEEE표준도 있다.

IEEE Std 1633-2008: IEEE recommended practice on software reliability

 

논문도 조사해보니, 굉장히 많더라는…

 

하지만, 논문들을 살펴보면서 여러가지 의문점이 들었다.

Q. 신뢰성을 검증하고자 하는 목적이 무엇인가? 솔직히 에러 좀 있으면 어떠한가? 그게 하나도 없어야 되는 이유가 있는가? 에러 있는거 알고도 릴리즈 할 수 있다. 중요한 거 아니면 다음에 릴리즈 하면 된다.

/ A. 좋다, 그렇다면 신뢰성 검증에서 사소한 에러는 제외하고 중요 에러만 샘플링해서 해보는건 어떤가?

 

Q. Reliability growth model을 이용해서 신뢰도를 예측한다고? 좋다. 그러면 그것을 어떻게 validation할 것인가? 내 생각에 Model의 정확성이 중요한데, 이것을 검증할 방법은 딱히 없을 것 같다.

Q. test sample의 randomness는 어떻게 입증할 수 있을까? 그거 중요할 것 같은데.. 10개짜리 test case를 copy & paste해서 100만번 돌린거랑 무작위 샘플 100만개 잡은거랑 다를 수 밖에 없을 것이다.

Q. 이 이론으로 검증할 수 있는 실용적인 유의수준이 어느정도 되는가? 1.0E-6할 수 있겠는가? 1.0E-9는 가능한가?

 

소프트웨어 신뢰성 하시는 분들이 이 글보면 도움을 주시길..

 

참고할 만한 글

소프트웨어의 신뢰성에 대한 개인적 의견

SOFTWARE RELIABILITY와 DO-178C/DO-278