위성 통신 버스 인터페이스 선택

테스트 엔지니어라면 일반적으로 작업에 맞는 도구 선택이 중요하다는 점에 동의할 것입니다. 잘못된 도구를 선택하면 많은 시간이 낭비되고 품질이 저하되지만, 올바른 도구를 선택하면 보다 빠른 시간에 바람직한 결과를 도출할 수 있습니다.

주요 도구는 통합, 체크아웃 및 대량 제조 테스트를 위한 전자 지상 지원 장비(EGSE) 또는 특수 체크아웃 STE(SCOS, STE는 특수 테스트 장비)를 구축할 때 측정 및 자극 계측 형태로 제공됩니다. 이러한 계측기에는 디지털 멀티미터(DMM), 오실로스코프, 웨이브폼 생성기 등의 기존 상용 제품뿐 아니라 벡터 신호 트랜시버, 올인원 오실로스코프와 같이 새로운 유형의 제품도 있습니다. 다양한 장단점을 살펴보고 평가해야 한다는 점을 고려하면 작업에 맞는 도구를 선택하는 일이 말처럼 쉽지는 않습니다. 이는 상품화된 계측기와 특수 계측기에 동일하게 적용됩니다. 그러나 위성 통신 버스 인터페이스는 같은 수준으로 엄격하게 고려되지 않는 경우가 많습니다.

검증 또는 통합 테스트에 사용되는 EGSE에 들어가야 하는 계측기 목록을 고려할 때, 테스트 엔지니어는 테스트 계획 요구 사항을 충족하는 완전한 측정 범위를 제공할 적절한 계측기를 찾기 위해 테스트 계획을 고려하고 시장에서 계측기를 평가하는 경우가 많습니다.

종종 특정 DUT(테스트 대상 장치)에 대한 테스트 계획에는 DUT를 특정 상태로 전환하거나 명령을 보내고 예상 응답을 수신하기 위한 추가 단계가 필요합니다. 이것은 비행 및 시스템 컨트롤러를 테스트할 때 특히 그렇습니다. 이러한 단계에는 품질 보증 검사 실행, 항공 전자 버스 자체에서 설계 검증 단계의 하위 집합 실행, 또는 추후 분석 또는 재생을 위한 응답 기록이 포함될 수 있습니다. 이 기능이 EGSE에 내장되어 있는지 확인하기 위해 테스트 엔지니어는 종종 DUT가 통신에 사용하는 프로토콜를 평가하고 필요에 맞는 계측기를 상용 기성품(COTS) 시장에서 찾습니다.

테스트 자산 플랫폼과 특정 DUT의 조합에 따라, 특정 항공 전자 버스 인터페이스 계측기가 선택할 수 있는 옵션은 광범위합니다. MIL-STD-1553, ARINC-429 및 SpaceWire와 같은 가장 일반적인 프로토콜을 고려하면 시장에는 이러한 요구를 충족할 수 있는 기성품을 제공하는 제공업체가 여럿 있습니다. 그러나 Fibre Channel(특히 SpaceFibre), 시리얼 RapidIO(SRIO), AFDX, 고속 데이터 버스(HSDB) 및 IEEE-1394b와 같은 고속 또는 백본 버스 또는 ARINC-708, ARINC-717 또는 ARINC-818과 같은 어플리케이션별 버스를 생각하면 옵션이 훨씬 더 복잡해지고 더 많은 사항을 살펴야 합니다. 

SpaceWire와 같은 많은 버스 인터페이스는 널리 보급되어 인터페이스 장비가 일반화되었습니다. 테스트 장비 공급업체가 물리적, 데이터 링크 및 네트워크 계층을 고정 기능 장치에 통합하는 것이 더 비용 효율적으로 되었습니다. 예를 들어, STAR-Dundee는 SpaceWire 버스 신호의 인터페이스 및 스위칭을 위한 여러 PXI 모듈을 제공합니다. 하드웨어 수준에서 널리 채택된 GPIB와 같은 다른 통신 프로토콜을 위한 장비와 마찬가지로 이러한 계측기는 특정 표준을 준수하기 위해 공급업체마다 유사하게 설계되는 경우가 많습니다. 

테스트 장비 벤더가 자신의 제품을 다른 제품과 차별화할 수 있는 곳은 프로토콜을 지원하는 특정 기능이나 기능이 구현되는 OSI(Open Systems Interconnection) 모델의 상위 데이터 계층에 있습니다. 여기에는 에러 감지, 스케줄링 유연성, 타임스탬프, 데이터 기록, 오류 삽입 등이 포함됩니다. 일부 제조업체는 모니터링 또는 디버깅을 위해 각 개별 OSI 계층의 데이터에 대한 접근도 제공합니다. 시스템 수준 검증 및 통합 테스트 요구 사항의 경우 미묘한 차이가 있는 많은 기능이 어플리케이션의 성공에는 그다지 중요하지 않은 경우가 많기 때문에 일반적으로 엔지니어의 선호도에 따라 결정이 내려집니다.

그림 1. ARINC-664p7/AFDX의 OSI 계층 단순화 도식도

테스트 시스템에 고속/백본 또는 어플리케이션 특정 프로토콜 인터페이스가 필요한 경우 한 때는 단순했던 선택 결정이 훨씬 더 어려워집니다. 테스트 엔지니어는 종종 이러한 프로토콜을 테스트 시스템에 통합하는 것과 관련된 복잡성을 간과합니다. 이러한 고성능 프로토콜 때문에 생긴 주요 과제 중 하나는 병렬 데이터 전송에서 직렬 데이터 전송으로의 이동입니다. 

병렬 버스의 클럭 속도에 대한 물리적 제한이 약 1GHz – 2GHz이며 개별 클럭 및 데이터 라인에 의해 발생하는 스큐가 더 빠른 속도에서 비트 에러를 유발할 수 있기 때문에 직렬 표준이 인기를 얻고 있습니다. 대신, 고속 직렬 버스는 병렬 버스의 속도 제한을 피할 수 있도록 하나 이상의 차동 신호에 데이터와 클럭 정보를 모두 포함하는 인코딩된 정보를 보냅니다. 또한 클럭 복구, 사전 강화(pre-emphasis) 및 균등화(equalization)와 같은 고급 기능을 갖춘 특수 고속 직렬 하드웨어 트랜시버를 사용하면 이러한 이점을 더욱 강화할 수 있습니다. 

고속 직렬 프로토콜 인터페이스를 위한 설계는 최신 FPGA 기술에 통합하기 적합합니다. 예를 들어, 최신 Xilinx FPGA의 멀티 기가비트 트랜시버는 30Gb/s보다 빠르게 작동할 수 있으므로 통신 프로토콜의 데이터 프로세서 역할을 하기에 이상적인 후보입니다. 이러한 계측기 하드웨어 설계의 복잡성 외에도 프로토콜 IP 자체도 일반 장비보다 훨씬 더 복잡합니다. 이는 해당 프로토콜이 훨씬 더 완전한 기능을 갖추고 있고, 측정 단위가 다를 정도로 데이터 속도가 빠르기 때문에 늘어난 복잡성으로 인해 데이터 요구 사항이 더 엄격한 경향이 있기 때문입니다. 

특정 고속/백본 또는 어플리케이션별 프로토콜 인터페이스를 EGSE에 통합할 때 엔지니어는 종종 몇 가지 옵션에 직면하게 됩니다.

• 옵션 1은 COTS 시장을 살펴보고 해당 인터페이스를 제공하는 공급업체를 찾는 것입니다. 다시 말하지만, 하드웨어 설계와 IP의 복잡성으로 인해 엔지니어는 고속 직렬 하드웨어 업체와 프로토콜 IP 코어 업체의 두 공급업체와 협력해야 하는 경우가 많습니다.

• 옵션 2는 IP 코어를 맞춤형 또는 상용 FPGA 평가 보드와 결합하여 EGSE에 통합하는 해당 DUT에 대한 내부 검증 팀의 설계를 활용하는 것입니다. 사내 맞춤형 설계를 활용하는 것이 매력적으로 보일 수 있지만 시간이 지남에 따라 지원 부담을 크게 증가시킬 수 있는 보이지 않는 위험이 종종 있습니다.

그림 2. "자체 개발" 테스트 시스템의 수명 주기 관리

이를 보여주기 위해 그림 2는 테스트 시스템의 수명에 대한 예와 시간이 지남에 따라 해당 시스템의 유지 관리 비용에 영향을 미치는 사건을 보여줍니다. EGSE가 완전히 설계된 후, 맞춤형 보드의 부품이 EOL(수명 종료)된다고 생각해 보십시오. 이는 반도체 기술 갱신 주기가 상업 시장을 반영하는 경향이 있기 때문에 결국 예상할 수 있는 것입니다. 그리고 검증 팀의 설계를 채택하는 경우 수명 주기 문제가 설계 요구 사항에 포함되지 않았을 가능성이 높기 때문에 특히 이런 일이 일어날 가능성이 높습니다. 

이와 같은 상황에서는 총 수명 주기를 버틸 만큼 해당 부품을 구매하고 예비 부품을 관리하거나 교체품을 찾고 하드웨어 설계를 재검증하는 것이 본질적으로 유일한 선택입니다. 또는 Windows 버전 변경 또는 Linux로의 이전과 같은 의무적 OS 업그레이드가 필요한 경우도 생각해보십시오. 그러면 드라이버를 다시 작성하고 소프트웨어 설계를 다시 검증해야 합니다. 테스터에 대한 요구 사항이 시간이 지남에 따라 변경되거나 새로운 기능을 추가해야 하는 경우 어떻게 합니까? 이 경우 펌웨어 또는 소프트웨어를 재설계해야 하거나, DUT 요구 사항에 따라 심지어 물리적 계층에 대한 재설계가 필요할 수 있습니다. 마지막으로, FPGA가 EOL되면 어떻게 됩니까? 이러한 부품의 경우 쉬운 업그레이드 방법이 없으므로 완전한 재설계가 필요한 경우가 많습니다. 

이는 테스트 시스템이 수십 년 동안 유지되어야 하는 항공우주 및 방위 산업에서는 매우 현실적인 상황입니다. 많은 경우 이러한 노후화 문제가 발생하면 원래 EGSE와 그 위에서 동작하는 테스트 소프트웨어 프로그램을 설계한 사람들이 그 자리에 없어서, 유지 관리를 지원할 수 없는 경우가 많습니다. 궁극적으로 초기 설계 비용은 수명 주기 동안 테스트 시스템 비용의 아주 작은 비율에 불과합니다.

대신, 엔지니어는 가능하다면 옵션 1인 COTS 기반 솔루션, 특히 테스트 및 측정에 사용하도록 설계된 솔루션을 고려해야 합니다. 위성 통신 프로토콜과 인터페이스하는 데 필요한 복잡한 소프트웨어 IP를 설계하고 관리할 수 있는 사내 역량이 있더라도, 맞춤형 하드웨어의 추가 유지 관리 부담 때문에 COTS 접근 방식으로 총 테스트 비용을 절감할 수 있습니다. 

수십 년 동안 항공우주 및 방위 산업은 NI의 모듈형 계측 및 어플리케이션 소프트웨어를 사용하여 제품 테스트 및 지원과 관련된 전반적인 비용과 위험을 줄여 왔습니다. 그 기간 동안 NI는 PXI 플랫폼을 개척했으며 이후 DC에서 mmWave에 이르는 600개 이상의 다양한 PXI 모듈을 출시했습니다. 기존 계측 외에도 NI, 파트너 네트워크 및 STAR-Dundee와 같은 PXI 플랫폼 부품을 제공하는 PXISA의 70여 기업 이상의 회원사가 제공하는 통합, 체크아웃 및 대량 제조 테스트 솔루션은 "작업에 적합한 도구"를 선택할 수 있는 유연성을 유지하면서 가장 포괄적인 범위의 PXI 기반 버스 인터페이스를 제공합니다.

제조 및 저장 테스트를 위한 디지털 항공 전자 기기 인터페이스

일반 인터페이스:

• MIL-STD-1553 
• RS-232/422/485 
• ARINC-429 
• CANbus 

고속/백본 인터페이스:

• Fibre Channel(특히 SpaceFibre)
• 시리얼 RapidIO 
• ARINC-664p7/AFDX 
• 1394b FireWire 
• 이더넷 (최대 40 GigE) 

어플리케이션별 인터페이스:

• ARINC-708 
• ARINC-717 
• ARINC-818 
• SpaceWire 
• DVI

테스트 엔지니어가 COTS 접근 방식이 가능하지 않고 맞춤형 엔지니어링이 필요하다고 판단하는 경우가 있습니다. 자주 인용되는 예는 특정 프로토콜의 맞춤형 버전을 통해 통신하는 DUT를 테스트하는 것입니다. 하지만 이러한 경우에도 테스트 EGSE의 일정 위험과 향후 유지 관리 부담을 줄이려면 맞춤형 설계를 피하는 것이 좋습니다. 맞춤형 설계 문제를 해결하기 위해 테스트 시스템에 COTS 통신 버스 인터페이스 하드웨어를 통합하는 것을 포함하여 우주를 위한 완전한 전자 기기 테스트 시스템을 구축하는 방법에 대해 자세히 알아보려면 이 어플리케이션 노트를 읽어 보십시오.