인터페이스 설계방법

인터페이스 설계 실무에서 주요 요소는 대부분 적용에 적합한 다음과 같은 다섯 가지 단계로 요약할 수 있다.

· 단계 1 : SOI - 운용환경관계 식별
· 단계 2 : 시스템 또는 품목 아키텍처 개발
· 단계 3 : 아키텍처 논리적 개체관계 제시
· 단계 4 : 운용 인터페이스 유스 케이스 제시
· 단계 5 : 물리적 인터페이스 특성 제시

이제 인터페이스 설계방법의 각 단계를 살펴보도록 하자.

1. SOI - 운용환경관계 식별
방법론의 첫 번째 단계는 대상시스템(SOI)에 상응하는 인터페이스를 나타내는 사용자 운용 환경 내에서 연관 개체를 식별하는 방법이다.

2. 시스템 또는 품목 아키텍처 개발
외부 시스템과의 논리적 또는 물리적 관계를 나타내기 위한 시스템 또는 개체 아키텍처를 개발하는 단계이다.

3. 아키텍처 논리적 개체관계 제시
시스템이나 개체 아키텍처 또는 확인된 사용자 요구분석에 기초하여 인공시스템과 운용환경과 같은 내부 및 외부 개체 사이에 논리적 개체관계를 제시하는 단계이다.
일반적으로 이 단계는 공식화된 인터페이스를 기술하는 단계이다.

4. 운용 인터페이스 유스 케이스 제시
각 시스템이나 개체 인터페이스에 대하여 인터페이스의 주요 운용 특성을 식별하는 단계이다.

· 인터페이스 이해관계자는 누구인가?
· 내용, 힘, 방향 어느 것이 인터페이스 항목으로 교환되어야 하는가?
· 언제 그리고 얼마나 자주 인터페이스가 나타나게 되는가?
· 지속적 또는 중간마다 인터페이스가 제시되어야 할 장소는 어디인가?
· 인터페이스는 어떻게 조정되며, 보안 및 사적 비밀이 유지되는 것인가?
· 무슨 상태에서 인터페이스가 일어나는가?

5. 물리적 인터페이스 특성 제시
운용 인터페이스 속성을 기초로 사용하여 그 인터페이스에 주요 운용 및 물리적 특성을 식별토록 하라.
데이터 교환 인터페이스의 경우, 인터페이스 속성은 connectors, pin-outs, grounding & shielding, protocol, timing & synchronization, data formats, handshakes, addressing, encryption, 그리고 표 1에 제시된 표준을 포함한다.

표 1. 인터페이스 속성 및 내용 기술

6. 인터페이스 설계 솔루션 개발과 문서화
운용, 논리적, 물리적 인터페이스 속성이 식별되고 제시됨에 따라 인터페이스 통제문서(ICD) 또는 인터페이스 설계기술서(IDD)에 대한 결과를 제시하라. 그리고 이를 설계 논리, 절충 결과 등을 문서화하라.

 

시스템 인터페이스 요구사항 구속 및 제시

인터페이스 요구사항을 구속하고 제시하기 전에 어디에 어떻게 인터페이스 요구사항이 문서화되어 있는지를 설정해 보자.
인터페이스 요구사항은 전형적으로 시스템 성능규격(SPS) 또는 품목개발규격, 시스템 인터페이스 절로 제시되어 있다. 어떠한 경우에는 소프트웨어 인터페이스 요구사항이 인터페이스 요구규격(IRS)으로 제시되기도 한다. 

1. 인터페이스 요구규격
IRS란 무엇인가? 미 국방 자료항목기술서(DID) DI-IPSC-81434에 따르면 “인터페이스 요구규격서(IRS)란 하나 또는 여러 시스템, 하부시스템, 이러한 개체 상호간에 하나 또는 여러 인터페이스를 달성하기 위하여 하드웨어 형상품목(HWCI), 소프트웨어 형상품목(CSCI), 매뉴얼 운영, 또는 기타 시스템 컴포넌트에 부과된 요구사항을 기술한 것이다. 

IRS는 어떠한 인터페이스라도 대상으로 하고 있으며……IRS는 시스템/하부시스템규격(SSS)의 보충자료로도 사용될 수 있다……그리고 소프트웨어 요구규격서(SRS) ……시스템과 CSCI의 설계 및 자격시험에 대한 기초자료로 사용된다.” [출처 : DoD Data Item Description (DID) DI- IPSC-81434, p.1]
가끔 사람들은 인터페이스 요구사항이 SPS 또는 품목개발규격에 기술된다면, 왜 별도의 인터페이스 규격을 작성해야 하는지를 묻곤 한다. 다음에 두 가지 그 이유가 있다.

· 시스템 외부 인터페이스
· 대상시스템 내부 인터페이스

이상적으로는 시스템 인터페이스 요구사항은 SPS 또는 형상품목(CI)에 대한 하위 레벨 품목개발규격(IDS)으로 단일화된 요구규격으로 작성되어야 한다. 이러한 질문에 대한 답변은 다음과 같다.

· 당신의 계약에서 무엇을 요구하는지.
· 계약 규격, 지적 자산, 고유 데이터, 보안과 같은 시스템 개발자에게 민감한 데이터를 보호하는 데 필요한 다른 요인은 없는지.

2. 인터페이스 규격에 대한 계약 요구사항
인터페이스 규격 요구사항에 관하여 사업제안서(RFP)와 계약 자료 요구 목록(CDRL)을 읽어보고 있다면 보다 면밀하게 검토해 보라. 만일 IRS CDRL이 보이지 않으면, SPS 또는 품목개발 규격에 나타난 인터페이스 요구사항을 애플리케이션에 따라 살펴봄으로써 다음과 같은 경우를 피해야 한다.

· SPS/IDS와 인터페이스 규격에 관한 두 가지 별도 문서를 유지하고 검증하기 위해 별도의 시간과 지출
· 별도의 검토와 승인에 대한 노력

· 시스템 관점에서 다음 문서와 함께 하나의 규격을 사용하는 개체로서 시스템 검증하기를 원한다.

· 수락시험절차(ATP) 한 세트
· 요구검증 매트릭스(RVM)
· ATP 데이터 한 세트

두 가지 별개의 규격서에 나타난 요구사항을 검증하기 위해 업무 수행, 자료 작성 및 협조를 동시에 수행해야 한다. 당신은 두 가지 규격서와 함께 ATP한 세트와 그 결과를 다루어야 한다. 이는 사실이지만, 당신은 여전히 이러한 별개의 복합된 결과를 어떻게 추적할 것인가에 대한 문제를 지니고 있다. 

만일 인터페이스 규격을 별도의 문서로 작성하지 않을 경우, 한 문서에 모든 시스템이나 개체 인터페이스 요구사항을 함께 작성하지 못하는 이유를 이해할 수 있다. 이를 보다 단순하게 다루도록 하라!

3. IRS는 내부 문서인가?
아니다. 사실상 많은 프로그램의 공통된 문제점은 “모든 내부 및 외부 인터페이스에 대한 하나의 IRS”를 개발하도록 사업을 제안하는 잘못된 정보를 제공하는 의사결정자가 있다는 사실이다. 이로 인해 비용을 낭비하고 불필요한 일을 하게 된다는 사실을 잊지 말아야 한다.

여기에는 별개의 IRS에 대하여 요구사항의 용량, 데이터 보안 분류 및 조달해야 할 별도의 이유가 발생하게 된다. 디폴트로 인터페이스 요구사항을 SPS나 품목개발규격에 정의토록 하라. 이때 만일 전체 인터페이스 요구사항 세트를 분리해서 작성해야 할 이유가 있다면, 그야말로 별도의 IRS를 작성토록 하면 된다. 

4. IRS를 외부에서 개발해야 할 필요가 있는가?
IRS는 사용자 조직과 하부계약자와 함께 계약관계를 도와줄 수 있다. 이럴 때 IRS는 인터페이스 관계에 있는 이해관계자의 일치된 의견을 나타내는 원칙적인 요구사항 세트를 기꺼이 별개로 다루게 된다. 궁극적으로 IRS 요구사항은 하드웨어 ICD와 소프트웨어 IDD로 문서화된 인터페이스 솔루션으로 진화한다.

5. 표준 IRS 템플릿
DoD는 데이터 요구사항을 나타내기 위하여 데이터 항목 기술(DID)을 적용하고 있다. DID DI-IPSC-81434는 하드웨어 형상품목(HWCI) 및 소프트웨어가 주된 시스템에 대한 소프트웨어 형상품목(CSCI)을 제시하고 있다. 

우리는 인터페이스 요구사항을 어떻게 기술할 것인가를 알아보았으며 이제 인터페이스 소유와 책임에 대하여 살펴보기로 하자.

인터페이스 소유와 책임

개인이나 통합제품팀(IPT)과 같은 개발팀에게 분담된 시스템 요소나 개체와 달리 인터페이스에 대한 분담은 어떻게 해야 할까? 여기에는 다음과 같은 여러 가지 방법이 있다.

· 위원회
· 구조분석 접근방법

1. 인터페이스 소유에 대한 위원회 운영방식
기술이사와 프로젝트 엔지니어들은 “관련 당사자끼리 해결”하는 방식으로 인터페이스가 되는 두 파트에게 소유권을 부여하는 방법이다. 주어진 상황과 사람의 특성에 따라 이 방법은 어떤 경우에는 매우 효과적이나 다른 경우에는 비효과적인 경우가 발생한다. 이 방법에서 발생 가능한 잠재 문제점은 다음과 같다.

· 인터페이스 당사자 간 그 인터페이스를 어떻게 해결할 것인지에 대한 견해 차이로 마찰이 발생할 수 있다.
· 상대적으로 우월한 사람이 너무 지나치게 주장하게 될 경우, 주장하는 파트에 혜택을 주는 기술, 비용 또는 일정에 차선책을 가져오게 된다.

이러한 경우가 계속될 경우, 우월한 파트가 대상시스템을 차선책으로 결정할 가능성이 커진다. 그러나 위원회 운영으로 발생하는 문제점을 해결할 수 있는 인터페이스 소유 및 통제를 위한 더 좋은 방법이 있다.

2. 구조적 인터페이스 소유와 통제
위원회 운영방식에 따른 문제점을 해결하기 위하여 시스템 성능규격서(SPS) 또는 품목개발규격서 및 이와 연관된 아키텍처에 대한 개인이나 개발팀에게 인터페이스 소유 및 통제권을 주는 방법이다. 인터페이스 당사자는 주어진 아키텍처 내에서 하나의 요소가 된다.
어떤 시스템은 조직 상호간에 기술과 프로그램 솔루션 둘 다 요구하는 외부 인터페이스를 지니고 있다. 이러한 경우 다음 토픽인 인터페이스 통제 실무그룹(ICWG)을 운영하는 방법이 있다.

3. 인터페이스 통제 실무그룹
인터페이스 통제 실무그룹(ICWG)은 시스템 또는 요소의 인터페이스 설계를 담당하는 요원 상호간에 공식적인 의사전달 링크를 구축하기 위해 만들어진 전형적인 그룹을 말한다. 특히 통합제품 및 프로세스개발(IPPD) 절차를 적용하는 ICWG는 인터페이스 설계 IPT 상호간에 연결을 구현하는 통합팀이나 시스템-레벨 엔지니어링 실무 그룹을 함께 통합하여 운영한다. ICWG 또는 이와 유사한 통합팀의 구성원은 각 계약업체, 계약부서 그리고 참여하는 정부기관 요원들로 구성된다. 외부 및 선정된 최상위 레벨 인터페이스를 주관하는 조달 프로그램 조직이나 내부 인터페이스를 다루는 주계약업체가 보통 ICWG 위원장을 지명한다. 

한 번 이해관계자가 인터페이스 요구사항과 적용에 동의하고 나면, 그들은 인터페이스 변경이 발생하면 어떻게 이를 통제하게 되는가? 이를 위해 몇몇 기관은 형상통제위원회(CCB)를 운영하거나 CCB에 추천 안을 건의하는 인터페이스 통제 실무그룹(ICWG)을 활용한다. 일반적으로 ICWG가 사용자 환경과 외부시스템을 포함한 전형적인 외부시스템 인터페이스를 설정한다. 계약 규모에 따라 ICWG와 CCB는 동일한 이해관계자로 구성되어도 좋다. 다른 경우에 ICWG는 사용자 및 계약조직으로부터 추천된 기술대표들로 구성된다.

하나의 조직 부서로서 ICWG는 하드웨어 ICD 또는 소프트웨어 IDD에 운용, 거동/논리적, 물리적 인터페이스 특성을 정의하고 이를 문서화한다. 인터페이스 이해관계자는 ICD 또는 IDD 문서를 검토한 다음 인터페이스 소유자의 승인을 받기 위해 차상위 레벨 팀에게 추천 안을 제출한다. 

승인되고 나면, ICWG 위원장은 IRS와 같은 인터페이스 문서에 기준을 제시하고 사용자에게 이를 공식적으로 제시하기 위해 프로그램의 형상관리자를 임명하게 된다. 베이스라인 후에 부가적인 변경이 요구되면, ICWG는 변경사항을 검토하고 프로그램 형상관리위원회(CCB) 승인을 위해 추천 안을 제시한다.

 

인터페이스 설계문서

인터페이스 설계는 시스템 블록선도(SBD), 개체관계도(ERD), 도식화된 와이어링, 시간 도표, 테이블, 기술서와 같은 다양한 방법으로 문서화한다. 대형 시스템일 경우, 이는 개별적으로 통제하는 수백 페이지 문서로 구성되어 있다. 이것을 어떻게 합리적으로 다룰 수 있을까?
시스템 엔지니어는 인터페이스 기술서를 작성하고 통제하기 위해 다양한 문서를 활용하고 있다. 이러한 문서로서는 다음과 같다.

· H/W 인터페이스에 대한 인터페이스 통제문서(ICD)
· S/W 인터페이스에 대한 인터페이스 설계기술서(IDD)

소규모 프로그램일 경우, 시스템/분야 설계기술서(SSDD) 또는 소프트웨어 설계기술서(SDD)가 별도의 ICD/IDD 문서를 가지는 것보다 인터페이스 정의를 문서화하기가 더욱 쉽다. 이러한 문서는 세부적인 인터페이스 설계를 발견하기 위해 단일 위치로 나타나게 된다. 비용을 절감하고 개발자에게 형상통제를 포함하고 있는 다양한 문서를 최소화하기 위해 적합한 문서를 사용토록 하라.

1. 인터페이스 설계기술서
소프트웨어에 적용하기 위해 인터페이스를 인터페이스 설계기술서(IDD)에 문서화한다. 이 방법은 별도 문서로 CSCI 특정 인터페이스 설계기술서를 고립시킬 필요가 있는 CSCI 소프트웨어에 대하여 자주 사용된다.

2. 인터페이스 통제문서
인터페이스 통제문서(ICD)는 인터페이스 통제도면, 인터페이스 요구규격서, 관련되거나 연동된 시스템이나 컴포넌트 상호간의 물리적 및 기능적 인터페이스를 나타내는 모든 문서를 포함한다. ICD는 ICWG나 유사 통합팀의 산출물이며, 이러한 통제문서를 활용하는 목적은 인터페이스 시스템 또는 요소들 상호간의 호환성을 구현하고 유지하기 위함에 있다.
인터페이스를 문서화하기 위해 흔히 쓰는 일반적인 방법은 인터페이스 통제문서를 사용하는 길이다. 일반적인 법칙으로 ICD는 하드웨어 인터페이스를 문서화하고 있다. 여기에는 다음과 같은 사항이 포함되어 있다.

· 단일 또는 여러 페이지 길이의 문서로 제시된다. 예를 들면, 도면통제, 컴퓨터 목록화 또는 수십 장의 세부사항으로 제시
· SPS, 품목개발규격 또는 IRS 요구사항에 대응한 세부 설계 솔루션으로 사용
· 전기, 기계 또는 광학 분야 인터페이스 특성 문서화
· 운용기술, 전선도식 도표, 아셈부리 도면 및 핀-아웃을 포함한 커넥터 세부도면 포함 제시
· 산업표준으로 설정되거나 계약으로 제시된 표준 그래픽 심벌 사용

· 모든 인터페이스 이해관계자가 ICD 내용을 동의하고 나면, 모든 관련 문서를 승인, 베이스라인 설정, 형상통제 및 공식적인 의사결정에 따라 제시된다. ICD는 형상통제위원회 또는 ICWG에 파견하여 통제된다.

3. 인터페이스 통제문서 개요
ICD는 계약이나 조직부서에서 특정 포맷을 제시하지 않는 한, 자유롭게 작성된다. ICD를 구조화하는 데에는 애플리케이션에 따라 다양한 방법이 있다. 가장 중요한 개요 부분은 다음과 같은 특정 전통적인 규격 형태로 작성된다.

· 1.0 서론
· 2.0 참조문서
· 3.0 요구사항

기본적인 구조를 넘어 기계, 전기 및 광학과 같은 인터페이스의 물리적 특성을 나타내는 3.0 요구사항 절에 주의를 기울여야 한다.

4. ICD/IDD 문서 수량
인터페이스를 식별하는데 먼저 알아야 할 점은 얼마나 많은 ICD/IDD 문서가 필요한지를 결정하는 일이다. 각 제품에 대하여 추상적 레벨과 관계없이 다음과 같은 그림 1에 나타난 옵션을 고려해야 한다.

· 옵션 A : 제품 A의 모든 인터페이스를 정의하기 위해 하나의 ICD를 생성하는가?
· 옵션 B : 각 제품 A 내부 인터페이스에 대하여 개별 ICD를 생성하는가? 예를 들면, A1~A2 ICD, A2~A3 ICD, 또는 A1~A3 ICD를 들 수 있다.

이러한 질문의 답에는 여러 가지 방법이 있다. 첫째, 당신이 제시한 각 문서는 유지하기 위해 비용이 증가한다. 일반적인 법칙으로 다음과 같은 경우가 아니면, 별도의 ICD/IDD 문서를 작성하지 마라.

· 정보의 양이 대형 페이지를 지니게 되면 다루기가 힘들게 된다.
· 지적 재산, 고유 데이터 그리고 안보적인 이유로 세부 내용을 별도로 취급할 수 있다. 이를 판단하기 위해 특정 인터페이스에 대한 접근을 인가된 사람에게만 부여하게 된다.

제품 레벨 및 그 하위레벨에서 그 품목의 모든 내부 인터페이스에 대하여 단일의 ICD로 시작하도록 하라. 왜 외부적인 인터페이스가 없느냐는 질문을 해 보아도 좋다. 여기에는 두 가지 이유가 있다. 첫째, 한 품목의 외부 인터페이스가 대상품목이 한 요소가 되는 아키텍처 일부분으로 차 상위 레벨 팀에 의해 통제되고 소유된다. SEIT가 제품 A의 외부 인터페이스를 소유하고 통제하도록 한다. 둘째, 한 품목의 인터페이스를 단일 문서로 제시하게 되면 그 문서가 크지 않을 경우, 독자에게 매우 편리하다.

5. 왜 유일한 ICD와 IDD로 작성되는가
앞서 ICD에 대한 논의는 왜 각 인터페이스에 대하여 별도의 ICD와 IDD 문서가 필요한지에 대한 새로운 의문이 발생한다.
첫째, 하드웨어 ICD와 소프트웨어 IDD 세부자료를 다 커버하는 단일 인터페이스 문서는 가질 수 없다는 것이 일반적인 법칙이다. 잠재력이 있는 리더는 여러 가지 문서를 연구하거나 추정할 필요 없이 한 문서에 단일 인터페이스에 대한 모든 세부사항을 제시하는 길이 합리적일 수 있다.

일반적으로 두 개의 문서를 다루는 것보다 하나의 문서를 다루는 것이 작성하고 유지하는 비용이 덜 든다는 사실을 생각해야 한다. 그러나 변경사항과 관계있든 없든 간에 모든 인터페이스 승인 이해관계자에게 변경사항을 나누어주는 일이 성가시고 비용도 많이 들게 된다는 사실이다. ICD/IDD 사용자는 무엇이라고 말하는가?

· 소프트웨어 엔지니어와 프로그래머는 전기 도식, 전선 도표 및 기계도면에 무관심하다.
· 하드웨어 엔지니어는 소프트웨어 데이터에 대한 도표 목록을 보는 데 관심이 없다.

 

따라서 다음과 같은 질문에 답해야 한다.

· 모든 품목의 인터페이스를 식별하고 있는가?
· 이해관계자와 협력하여 특히, 제품통합팀(IPT)과 함께 일하고 있는가?
· 유일한 ICD/IDD 또는 통합된 ICD/IDD에 대한 효용성을 구분하라.
해당 품목이 하드웨어와 소프트웨어 인터페이스를 요구한다는 결정이 내려지면, 모든 하드웨어 또는 소프트웨어 인터페이스가 하나 또는 여러 개의 ICD/IDD 문서로 작성되어야 하는지를 결정해야 한다.

지금까지 우리가 관심을 둔 초점은 개별적인 인터페이스에 있었다. 이는 비용과 리스크를 증가시키는 모든 고유의 인터페이스에 대한 잠재를 고려하지 않고 있다. 이제 우리는 그 초점을 이러한 두 가지 요인을 최소화하기 위한 인터페이스 표준화를 다루어 보기로 하자.

인터페이스 표준화

어떤 형태의 시스템 설계와 마찬가지로 인터페이스 설계 또한 비용, 일정, 기술을 최소화하는 한편 특정 요구사항을 충족시키며 리스크를 지원해야 한다. 당신이 신규 인터페이스 솔루션을 설계할 때 발생하는 모든 시기에 당신은 입증되지 못한 인터페이스에 대한 위험을 완화하도록 준비해야 한다. 

이러한 리스크에 따른 영향을 감소하는 방법은 이미 입증된 설계 솔루션을 사용하는 길이다. 부가적으로 당신이 선택한 어느 기술 솔루션도 아주 짧은 기간 내에 진부화 되고 있다는 사실을 생각해야 한다. 예리하게 비교해 보면 특히 컴퓨터와 같은 시장에 나와 있는 상용 제품은 완전히 새로운 시스템을 요구하지 않는 한 시스템 능력과 성능을 유지하기 위하여 기술적 업그레이드를 수용할 수 있도록 설계가 요구되고 있다. 

산업시장 요구를 충족시키는 하나의 방법은 라인교체품목(LRU)을 모듈화, 상호교환, 융통성 및 유지보수 가능성을 달성하는 표준 인터페이스를 설정하는 길이다. 이것은 무엇을 의미하는가?

컴퓨터는 마더보드(LRU)에 적용된 표준 버스구조와 함께 인터페이스를 나타내는 커넥터로 형성된 PCB 보드(LRU)를 포함하고 있다. 새로운 프로세서 기술이나 다른 능력을 요구하게 되면, 사용자는 PC 보드(LRU)를 동일하거나 더 좋은 능력을 지닌 새로운 것으로 교체하게 된다. 이리하여 인터페이스 표준은 비용과 리스크를 낮게 유지하면서 신규 기술과 능력을 부과할 수 있는 기회를 제공하게 된다.

앞에서 논의한 바와 같이 우리는 인터페이스를 분석, 설계 및 통제함에 있어 쟁점사항과 도전해야 할 사항을 알아내야 한다.
독립적인 인터페이스 설계에 따른 영향을 최소화하고, 상호 운용성을 증대하며, 상용 컴포넌트 사용을 극대화하고, 향후 성능을 융통성 있게 개량하기 위하여 개방형 시스템 접근방법을 적용한다. 이러한 접근방법은 인터페이스 통제계획에 있어 매우 중요한 요소를 차지하고 있다. 개방형 시스템 접근방법은 시스템의 내부 및 외부 인터페이스를 명시하기 위해 산업계에서 널리 사용되고 있는 규격서와 표준을 선택해야 한다. 이러한 개방형 시스템은 다음과 같은 특성을 갖고 있다. 

· 인터페이스 영향이 없는 컴포넌트를 선정하여 설계의 유연성을 증대시키기 위하여 기능을 분할하거나 모듈 설계를 증가
· 산업계가 인정하는 표준기관이나 전문협의체에 의해 개발되거나 채택된 표준에 기초함으로써 인터페이스 또는 프로토콜에 대한 정의를 분명하게 하고 이를 광범위하게 사용
· 시스템에 대한 영향을 최소화하면서 추가하거나, 상위 성능 요소를 도입하여 확장 또는 성능 개량 구현
 
이러한 정보기술표준에 대한 일반적인 지침은 통합 기술 아키텍처로 제시되고 있다.

그림 1. 시스템/제품레벨 인터페이스 기술 옵션

 

인터페이스 정의와 통제 도전사항

인터페이스 정의, 설계, 개발, 운용 및 지원활동은 여러 시스템에 공통적인 도전사항과 직면하게 된다.

· 도전 1 : 외부 인터페이스 미충족
· 도전 2 : 인터페이스 소유 및 통제 미충족
· 도전 3 : 인터페이스 위협 식별 및 취약
· 도전 4 : 인간과 환경 안전 및 보건 리스크
· 도전 5 : 적합성 및 상호운용성 미충족
· 도전 6 : 인터페이스 가용성 미충족
· 도전 7 : 인터페이스 신뢰성 미충족
· 도전 8 : 인터페이스 유지보수성 미충족
· 도전 9 : 외부 위협에 대한 인터페이스 취약성
· 도전 10 : 인터페이스 통합 절충과 고장완화
· 도전 11 : 외부 전력-가용성, 품질, 및 보조
· 도전 1 2: 아날로그와 디지털 신호 접지 및 차단
· 도전 13 : 인터페이스 전자기 복사

1. 외부 인터페이스 미충족
“그 시스템은 외부 시스템 XYZ와 인터페이스 능력을 제공해야 한다”고 획득자가 시스템 성능규격서(SPS)에 제시하고 있는 계약이 매일 이루어지고 있다. 조사에 따르면, 획득자는 대상시스템(SOI)을 연결하기 위한 외부 시스템 XYZ 소유자로부터 어떠한 동의나 약속을 하지 않아도 좋다. 이는 정상적으로 획득자의 책임이며 공식적인 입찰 이전에 제시되어야 한다. 이상하게도 획득자는 시스템 개발자에게 ‘약속사항’에 대한 책임을 부여한다. 이는 계약의 내용과 조건(T&C)에 대하여 사인한 사람을 말한다.
어떠한 경우에 이 방법은 특별히 시스템 개발자가 다음 사항을 가지고 있을 경우, 적합하다고 볼 수 있다.

· 전문가, 능력 및 자원
· 인터페이스 당사자와 설정된 관계

따라서 이러한 업무를 수행하기 위하여 시스템 개발자와 계약을 추진하는 것이 바람직하다. 치명적인 쟁점사항은 외부 시스템 XYZ 담당조직이 획득자 조직의 일부일 경우에 발생한다. 따라서 계약이 성사되기 전에 납품 시 시스템을 통합하기 위하여 획득자 또는 사용자가 외부시스템 담당자와 무슨 내용을 동의해야 하는지를 철저하게 검증해야 한다.

2. 인터페이스 소유 및 통제 미충족
각 시스템 인터페이스는 개인, 조직 또는 인터페이스 통제그룹(ICWG) 등의 담당자를 지정해야 한다. 담당자는 △인터페이스 정의, 설계 △개발 △시스템 통합, 시험 및 평가(SITE) △시스템 운용 및 유지 △폐기에 관한 사항을 통제해야만 한다.
인터페이스 담당자로써 개인이나 조직은 시스템 운용, 유지보수 및 교육훈련에 대한 전반적인 사항을 제공해야함과 마찬가지로 인터페이스 설계 베이스라인에 대한 변경사항을 검토하고 승인해야 할 책임을 져야 한다.

3. 인터페이스 위협 식별 및 취약
시스템 인터페이스 설계는 이미 잘 알려진 인터페이스를 기본으로 한다. 실제로는 국방시스템이나 네트워크처럼 외부 위협과 공격에 취약한 운용상의 시스템 인터페이스로 나타난다. 이러한 시스템은 잘 알려지지 않았거나 잘 모르는 체계일 경우이다. 획득자와 시스템 개발자는 다음 사항을 철저히 검증하여 사용자와 지원조직과 함께 수행해야 한다.

· 시스템 위협을 인식하고 이해
· 대상 시스템 인터페이스가 어떻게 위협을 극복할 수 있는지를 정의

4. 인간과 환경 안전 및 보건 리스크
어떠한 운용시스템일지라도 안전, 보건, 인간복지, 자산 또는 환경에 대한 잠재 위협을 지니고 있다. 시스템 인터페이스를 설계할 때, 열 발산, 독극물, 누수와 같은 잠재된 시나리오를 철저하게 분석해야 한다. 이는 보건과 안전 리스크에 이르게 하고 수용 기준에 이르도록 처방을 해야 한다.

5. 적합성과 상호운용성 미충족
각 인터페이스가 잘 알려져 있고 유능한 담당자라고 가정하고, 시스템이나 개체 인터페이스는 운용 환경 시스템 요소가 운용, 거동 및 물리적인 면에서 적합하고 상호운용 가능해야 한다.

6. 인터페이스 가용성 미충족
인터페이스 가용성은 외부적인 것과 내부적인 것 두 가지 주요 상황에서 치명적인 쟁점사항이다. 각 내부 인터페이스는 의도하는 임무를 시작할 때, 준비상태가 가용해야 한다. 만일 외부 시스템이나 이와 연관된 인터페이스가 실패하면, 당신 시스템에 대한 고장배제를 어떻게 하며 위기 상황에서의 소스로부터 임무자원 요소 데이터를 도출할 수 있는지를 고려해야 한다.

7. 인터페이스 신뢰성 미충족
필요 시, 인터페이스 능력이 가용하다면, 그 인터페이스가 시스템이나 개체 규격에서 요구된 성능레벨까지 의도하고 있는 임무 수행을 신뢰할 수 있는가라는 질문을 하게 된다. 각 인터페이스는 임무과정을 통해 그 능력을 유지하며 임무수행에 대한 신뢰성을 보장할 수 있도록 설계해야 한다. 이러한 주제는 인터페이스 고장 허용 및 중복으로 다루어지고 있다.

8. 인터페이스 유지보수성 미충족
시스템 임무수행 간 중단 상태를 최소화하기 위하여 인터페이스는 특정 기술레벨로 유지할 수 있어야 하며 임무준비, 수행 및 수행 후와 같은 전 임무 운용단계에 적합한 도구를 제시해야 한다.

9. 외부 위협에 대한 인터페이스 취약성
시스템이 납품된 이후에 인터페이스 담당자는 지속적으로 인터페이스 운용과 연관된 메커니즘과 프로세스에 대한 성능을 모니터링 해야 한다. 부가적으로 담당자는 시스템 운용환경에서 잠재 위협 또는 인터페이스 진화에 따른 의구심과 취약점을 평가해야 한다.

10. 인터페이스 통합 절충과 고장완화
인터페이스 통합은 특정 인터페이스를 통해 절충과 고장완화를 위해 얼마나 잘 설계했는지에 달려있다. 인터페이스 보안 메커니즘은 접근성 잠금장치, 안전 체인, 추적, 휠, 필터, 쉴드, 항공기 케이블 후크, 안전망, 안전 선로, 파라슈트, 압력 완화 벌브, 위기 차단 벌브, 비상 전력 차단과 같은 사례를 포함하고 있다.

11. 외부 전력-가용성, 품질 및 보조
엔지니어는 시스템, 제품, 하부체계 등 대상시스템의 내부설계에 보다 초점을 두고 있다. 그러다 전력 소스, 속성, 품질과 같은 외부 인터페이스 연구를 미쳐 염두에 두지 못할 경우가 발생한다. 일반적으로 상용 전력은 110볼트 또는 +28 vdc 전력이 항상 가용하고 코드에 연결만 하면 되는 것으로 믿고 있다. 이와 같이 전력을 믿고 있음으로 인해 50Hz, 60Hz, 400Hz에 대한 전력의 진폭과 주기에 대한 허용오차를 간과하기가 쉽다. 전력 요소 또한 고려해야 한다. 드디어 전력이 지속적으로 공급 가능한지, 주기적인 운용시간과 단전 등이 최고 운용시간에 가능한지에 대한 질문을 해 보아야 한다.
외부 시스템이 당신이 철저하게 그 인터페이스를 조사하고 분석할 때까지 항상 가용하다고 가정하지 않는 것이 바람직하다. 부가하여 전력담당기관에서 전력예산자원을 할당하겠다는 문서를 작성해야 한다. 그리고 당신 시스템에 해당 전력을 공급하겠다는 약속을 받아야 한다. 이는 전력 품질과 여과에도 동일하게 제시되어야 한다.
최종적으로 다음과 같은 내용을 평가하도록 하라.

· 임무수행 중에 데이터 손실을 예방하기 위한 백업 전력
· 장비에 데이터 손실이나 파손을 최소화하기 위하여 전력 중단 상태가 발생하지 않도록 주의사항 제시

12. 아날로그와 디지털 신호 접지 및 차단
아날로그와 디지털 신호 접지 및 차단 인터페이스는 위에서 언급한 전력 쟁점사항과 유사하다. 예를 들면, 분석의 깊이 및 요구자원에 대한 분석에 대하여 늦장을 부리는 경우이다. 전형적으로 단일 전력 접지만이 외부 소스로부터 가용하다. 이는 당신 시스템이 잡음이나 접지 루프를 교환하면서 파손되는 접지전력에 측량 데이터나 손실 데이터를 수집할 때 특별히 발생한다. 다음 사항을 철저하게 관리토록 하라.

· 어떤 외부 접지 시스템이 가능한가
· 어떤 외부 시스템이 전력 및 시그널 접지에 적용되고 있는가
· 다른 시스템이 이러한 소스와 인터페이스를 일으킬 때 무엇을 발견하고 경험했는가

13. 인터페이스 전자기 복사
전력과 시그널 인터페이스는 다른 데이터에 민감한 기기와 연결되거나 외부 정탐 장비에 의해 추적될 수 있는 전자기 시그널을 방출한다. 대부분 엔지니어는 케이블로부터 시그널 차단과 접지를 고려하게 된다. 그러나 시그널 차단과 접지는 설비와 마찬가지로 기계 부속함 내에 포함된 시그널 소스로 적용한다.

 

적용 원칙

요약해서 앞에서 우리는 시스템 인터페이스 분석, 설계 및 통제 실무에 관한 전용하는 원칙을 설정할 수 있는 기초를 제공할 수 있었다.

· 원칙 1 : 규격서와 시스템, 그리고 품목 사이의 인터페이스는 그 품목을 나타내는 아키텍처에 적합한 조직에 의해 책임지고 통제되어야 한다.
· 원칙 2 : 한 개체 규격 내에 있는 모든 인터페이스의 운용, 물리적, 데이터 요구사항을 문서화하라. 별도의 이유가 있을 경우, 독립된 소프트웨어 IRS를 작성하라.
· 원칙 3 : ICD는 하드웨어 인터페이스를 문서화하고 IDD는 소프트웨어 인터페이스를 문서화한 것이다.

 

요약

시스템 인터페이스 분석, 설계 및 통제에 대해 논의를 하면서 다음과 같은 내용을 도출했다.

· 인터페이스를 어떻게 식별하며 이를 IRS, ICD, IDD 문서로 작성되는지 기술
· 시스템 인터페이스를 식별하고 정의하는 방법 설정
 · ICWG가 어떻게 시스템 인터페이스를 통제하는지 기술
· 인터페이스 표준에 대한 공통 사례 제시
· 인터페이스 정의 및 통제의 공통 도전사항과 쟁점사항 식별

1. 일반적 예제
(1) 서론에서 제시된 이 장에서 알아두어야 할 사항에 대하여 답변토록 하라.
(2) 이전 장의 일반적 예제 또는 신규 시스템을 선정한 후 이 장에서 나온 사항을 적용해 보자. 이전에 개발된 시스템 아키텍처를 사용하여 당신이 어떻게 인터페이스를 관리할 것인지에 대한 기술관리계획서(TMP)를 준비해야 한다고 가정하여 작성토록 하라.
(a) 인터페이스를 어떻게 식별, 책임관리 및 통제해야 할 사항을 기술한 기술관리계획서를 작성하는 지침을 먼저 준비해 보라.
(b) 인터페이스를 IRS, ICD 및 IDD로 문서화하는 방법을 기술해 보라. 각 문서에 어떠한 사항을 기술해야 하는지를 작성해 보라.

2. 조직중심 예제
당신 조직의 지휘계통을 연구해 보자.

(1) ‌인터페이스 식별, 소유 및 통제에 부과된 최소한의 요구사항은 무엇인가
(2) 표준 IRS, ICD, IDD를 사용하도록 요구하고 있는가
(3) 조직의 IRS, ICD, IDD 구조는 무엇인가
(4) ‌누가 각 계약 프로그램에서 IRS, ICD, IDD를 통제하고 있는가

당신 조직 내에서의 소형, 중형, 대형 계약 프로그램을 살펴보라.

(1) ‌그 프로그램에 부과된 계약자료 요구목록(CDRL)에 IRS, ICD, IDD와 연관된 무슨 요구사항이 제시되어 있는가
(2) 계약에 작성 포맷을 제시하고 있는가
(3) ‌그렇지 않다면, 각 문서형태에 어떠한 포맷을 사용하고 있는가
(4) 인터페이스 소유 및 통제는 어떻게 설정되어 있는가
(5) ‌프로그램 수행자가 다음 프로그램에서 개선되어야 할 새로운 교훈은 무엇인가.

민성기  시스템체계공학원장(sungkmin0@gmail.com)