2017년 3월 23일 목요일

예비 위험원 분석 절차 (PHA Process)

예비 위험원 분석 과정은 크게 5 Steps로 나뉜다. 개별 Step에 대해서 살펴보면 다음과 같은 특성을 지닌다.

(1)   예비 위험원 분석시트 결정 안전성 관리자는 예비 위험원 분석을 수행하기 위해 가장 적합한 예비 위험원 항목을 결정해야 한다. 결정해야 할 항목은 아래와 같다.

 1. 예비 위험원 결정 항목
  
(2) 예비위험원 분석 기본 교육 실시
안전 관리자는 해당 개발 구성원들에게 예비 위험원 분석을 수행하기 위한 기본 적인 교육을 실시해야 한다. 교육의 내용은 다음과 같다.

 2. 교육 내용

(3) 예비위험원 분석 Sheet 배포 및 작성
안전 관리자는 최초 예비 위험원 분석(PHA)을 위해 예비 위험원 분석용 시트를 구성원에게 배포한다. 구성원은 예비 위험원 분석 시트를 작성한다. (최소한 위험 원과 원인에 대해 도출 가능하다).

(4) 예비 위험원 분석 시트 취합 및 정리
안전 관리자는 구성원이 작성한 예비 위험원 분석 시트를 취합한다. 안전 관리자 는 취합된 예비 위험원 분석 시트에 분석된 위험원을 정리(시스템 수준과 동일 위험원 별로 정리)한다.

(5) 예비 위험원 분석 실시
안전 관리자는 예비 위험원 분석 시트 내용을 최종 결정하기 위한 회의를 소집 하고 진행한다. 회의 내용은 다음과 같다.
3. 회의 내용

PHA 기법의 수행에 대한 절차가 완료 되었다면, 실제로 해당 기법에 대한 입력 물은 충분하였는지, 해당 절차는 준수하였는지에 평가를 수행해야 한다.


2017년 3월 22일 수요일

예비 위험원 분석(Preliminary Hazard Analysis : PHA)

PHA는 시스템 생명주기 중 개념설계 및 RAMS 목표 설정단계에서 장치의 기능 요구사항을 바탕으로 간소화된 기능별 위험원(Hazard)을 도출한다. 그리고 위험도 (Risk)를 평가하여 안전대책 수립에 의한 위험도 제어의 필요성을 검토하기 위해 수행한다. PHA 수행을 통해 도출된 PHA 위험원은 허용할 수 있는 수준으로 위험도를 제어해야 하는 대상이다

PHA는 본격적인 위험원 분석을 수행하기 위한 준비단계에서의 가장 우선적으로 수행되는 위험원 분석을 의미한다. 따라서 PHA 기법은 시스템 설계 안에 내재되어 있거나 관련되어 있는 위험요인, 위험상황, 사건 등을 제품 설계단계 초기에 식별 및 제거해 내고자 하는 것이다. 구체적으 로 시스템 내의 어디에 어떤 위험원이 존재하는가? 어느 정도의 위험 상태에 있는가? 안전 기준 및 시설의 수준은 어떠한가를 정성적으로 평가한다. 이와 같은 과정을 통하여 개발 시스템의 주요 위험요인은 개발 초기 단계부터 제거되거나 최소화되고, 혹은 통제될 수 있게 된다.

PHA 위험원 분석 기법은 다음과 같은 사항들을 고려하여 수행되어져야 한다.

l  시스템에 관한 모든 주요한 위험원을 식별하고, 간략하고 포괄적으로 기술한다. 시스템 위험원은 시스템 요구사항 사양서를 기반으로 생성된 아키텍처 산출물과 특히 기능요구사항을 기반으로 위험원을 식별하게 된다. 위험원은 대상 물리적 구조가 지닌 다양한 운용적 모드 차원에서 수행되어야 하는 기능적 차원에서 발생될 수 있는 오류적 기능을 기반으로 위험원 분석을 통해 식별된다.
l  사고를 초래하는 요인을 식별한다. 위에서 언급한바 와 같이, 사고요인은 물리적 구성품이 지니고 있는 기능적 정보를 기반으로 오작동 또는 동작실패로 인해 초 래될 수 있는 이벤트(Event)의 원인을 식별하게 된다.
l  PHA에서는 도출된 위험원에 대해 원인과 영향을 분석하여 위험원을 처리 할 수 있는 수정조치 방법이나 대책을 수립한다. 식별된 위험원으로부터 초래할 수 있 는 문제를 해결하기 위해서 안전대책이 반영한 설계적 조치를 반영해야 한다.

최초 안전성 활동으로 수행된 PHA는 차후 다음과 같은 사항에 적용된다. 도출된 위험원 분석의 최상위에 속하는 사항을 결정하는데 기초자료로 제공된다. 원활한 PHA를 수행하기 위해 관련된 모든 인원은 다음과 같은 사항을 준수해야 한다. 다음 사항은 PHA SHA, SSHA, IHA, O&SHA와 같은 위험원 분석활동에 공통으로 적용된다.

l  RAMS 관리자는 PHA를 수행하기 위해 회의를 소집해야 한다.
l  관련된 각 팀의 팀장은 회의를 적극적으로 지원해야 한다.

l  RAMS 팀은 PHA작성 Sheet를 준비하여 배포해야 한다.

철도 차량 안전성 활동을 위한 주요 위험원 분석기법과 절차

운영기관, 차량제작기관, 성능시험기관, 제작/감독기관 이렇게 총 4개 조직(기관)을 통해서 안전성 활동을 수행하도록 지침으로 규정하고 있다.  제시된 활용 대안의 상이한 점은 FTA 또는 FMEA 기법 중 어느 기법을 먼저 수행하느냐에 따라 다른 접근안을 제안하고 있다.


그림 1. 철도차량 안전지침 및 안전성 활동 절차

철도시스템의 위험원 분석기법의 위험도 분석 평가기준

철도시스템의 위험원 분석기법은 안전 무결성 등급별로 [표 1]와 같이 복수로 사 용될 수 있다. 이러한 위험원 분석 및 위험도 평가를 위한 각 방법들은 안전계획 서에 제시된 방법에 따라 안전성 활동이 수행해야 하며, 이의 입증 자료 또한, 제 시해야 한다.

표 1. 시스템의 위험원 분석 방법 (Reference)


도출된 위험원들의 위험도 평가는 표준에서 정의하고 있는 위험도 매트릭스 방법 을 활용하여 적용될 수 있다. 위험도 매트릭스 방법을 적용한 위험도 평가는 다음 과 같다.
철도 도메인에서 많이 쓰이는 위험도 평가 기준은 [표 29]로부터 [표 31] 이다. 해 당 정보의 활용을 통해 위험도 평가요소인 발생빈도, 심각도, 허용수준에 대한 평 가를 수행하게 된다. 본 가이드에서도 위험도 평가를 위한 지표로 [표 29~31]이 활 용되지만, 위험도 평가에 대한 지표는 산업군 별로 상이하며, 국내 철도 도메인에 서 또한, 사용하는 위험도 평가 지표가 사용되고 있다는 점을 본 가이드의 활용자 는 인지하여야 한다.   

2017년 3월 21일 화요일

Best Practices for Preventing and Responding to Distributed Denial of Service (DDoS) Attacks


참석자
Will Hayes - Principal engineer at the Software Engineering Institute
Rachel Kartch - Network analyst team lead in CERT Division of the SEI

4D 업종이 되어가는 소프트웨어 개발

불과 얼마 전까지만 해도 소프트웨어 개발에 대한 수요와 공급은 기하급수적으로 늘어갔고 이 때문에 많은 사람들이 소프트웨어 개발자를 희망했다. 하지만 새로 유입되는 상당수의 개발자가 소프트웨어 업종 자체를 포기하는 경우가 발생하고 소프트웨어 개발 업체의 수도 예전만 못하다. 기존의 3D 업종에서 꿈이 없다(Dreamless)는 의미가 포함된 4D 업종으로 분류되고 있는 소프트웨어 개발에 대해 고려대학교 이영환 박사, 신명소프트 박승식 대표를 만나 살펴보기로 한다.

Q: 안녕하세요. 이번 주제는 다소 비관적인 주제가 될 것도 같습니다만 소프트웨어 개발을 하는 사람이라면 한번 이상은 고민하는 문제가 아닐까 생각됩니다.

소프트웨어 하나 잘 만들어서 대박이 나고 전세계 사람들이 주목하는 그런 시대가 있었죠. ‘90년대에 들어서면서 우후죽순처럼 생기던 전자계산학과, 컴퓨터공학과에 지원자가 한없이 넘치기도 했습니다. 그만큼 인기가 많았다는 것이죠. 어떻게 보면 지금도 소프트웨어에 대한 인식은 아주 나쁘지 않습니다. 다만 소프트웨어 개발자들의 생각이 회의적이라는 것이 문제죠.
냉정하게 컴퓨터나 소프트웨어 업의 인기가 올라갔던 이유는 XT, AT, 386이라 불리던 인텔의 80시리즈가 나오면서부터 였습니다. 컴퓨터 전공의 학생들조차 학교에서 쉽게 다루지 못했던 컴퓨터가 가정에서 쉽게 접할 수 있게 되었던 것이죠. 486, 586 컴퓨터를 거쳐 현재의 i5, i7 등의 CPU가 나타나고 있습니다.
하지만 중요한 점은 컴퓨터나 소프트웨어 개발의 인기는 식지 않았는데 소프트웨어 개발자의 인기는 점점 줄어들고 있다는 점입니다. 더 세부적으로 말하면 소프트웨어 개발자의 인식은 점점 회의적으로 변하고 있다는 것이죠.


Q: 하드웨어와 소프트웨어의 인기는 그대로인데 왜 소프트웨어를 만드는 개발자들의 인식은 점점 회의적으로 바뀐다는 것이네요. 실제로 우리나라 개발 업체에서도 개발자 문화 바꾸기나 개발자 기 살리기와 같은 운동이 펼쳐지기도 합니다.

최근에 애자일 문화가 보급되면서 다소 활기를 띄는 것은 사실이지만 한계를 느끼는 경우가 대부분이라는 보고가 계속 나오고 있습니다. 아마도 소프트웨어 개발이 가지고 있는 특성과 회사라는 조직이 운영되는 방식과 차이를 보이고 더 깊은 이유는 갑을 관계로 형성된 계약 관계에 있지 않나 싶습니다.

전체 보기 >>>

4차 산업혁명과 비즈니스의 변화

4차 산업혁명에 따른 미래 사회 변화는 기술, 산업 구조, 고용 구조 그리고 직무역량 등에서 나타날 것으로 예측된다. 기술과 산업 간 융합을 통해 기존 산업 구조를 스마트 비즈니스 모델로 변화시킬 것으로 보인다. 4차 산업혁명의 특징인 초연결성과 초지능화는 스스로 생각하고 판단하는 스마트 형 팩토리(Smart Factory)와 같은 새로운 비즈니스 모델을 이끌어 내겠지만 스마트에 대한 적응이 어느정도 되어 있는 상태이기 때문에 적응은 그리 어렵지 않을 것으로 보인다. 이미 제조업에서는 인간의 노동력을 줄이고 자동화한 소 품종 다량 생산에서 스마트 기능이 접목되면서 다 품종 소량 생산의 맞춤형 개발도 시도하는 추세다(그림1).

<그림1> 스마트 산업의 시장 사이클



출처 : Global Market Strategy(삼성증권), 2016

한가지 주의해야할 사항은 산업에서 인간의 노동력을 대체하여 기계화 하는 것은 이미 2, 3차 산업혁명에서 이루어진 사항이다. 많은 전문가나 보고서가 4차 산업혁명으로 인해 노동력이 감소되고 인간의 직업군이 줄어들 것으로 예측하고 있지만 스마트 적인 관점으로 본다면 인간이 할 수 없는 부분을 담당하면서 또다른 직업군을 만들어 낸다고도 볼 수 있다(그림2).

<그림2> 스마트화가 가능한 직업 분포
출처: CEDA(Committee for Economic Development of Australia), 2015

그림4에서 보는 것처럼 단순 노동(우측)에 가까운 부분과 숙련(좌측)에 가까운 부분이 스마트화 하는데 좋은 대상이 될 것으로 보인다. GE의 2016년 보고에 의하면 빅데이터, 인공지능 등 4차 산업혁명과 관련된 기술 분야에서 200만개의 새로운 일자리가 생기고 그 중 65%는 신생 직업이 될 것이라고 전망하고 이러한 신생 직업은 대부분 소프트웨어 개발 분야에서 나타날 것이라고 하고 있다. 이런 현상이 일어나는 가장 큰 이유는 기존 산업의 스마트화를 위해서는 사물 인터넷, 빅데이터, 인공지능, 그리고 이들을 연결할 클라우드가 필요하고 운용을 위한 소프트웨어가 반드시 필요하기 때문이다. 각 산업에서는 스마트화를 위해 기하급수적으로 4차 산업혁명을 위한 혁신을 요구할 것이기 때문에 빠르고 효율적인 적용을 위한 소프트웨어 관점의 표준화된 플랫폼이 필요한 것이다. 또한 이러한 표준 플랫폼은 산업별로 독립적으로 존재하는 것이 아니고 추후 산업 간 융합을 위해 상호 보완적이고 연결성이 높도록 구성하는 것이 좋다.