[시스템 인터페이스 분석, 설계 및 통제(3)] 인터페이스 설계방법
[시스템 인터페이스 분석, 설계 및 통제(4)] 인터페이스를 적용한 시스템 능력 구성

인터페이스 표준화

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

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

산업시장 요구를 충족시키는 하나의 방법은 라인교체품목(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)