강화 시스템의 독립성 및 유지보수를 위한 고급 로켓 엔진 테스트 아키텍처

2021년에는 로켓을 궤도에 올려놓으려는 시도가 역사상 그 어느 해보다 많이 이루어졌습니다.¹ 전세계 기업과 정부는 146회의 비행을 시도했으며 궤도 안착에 135회 성공했습니다. 2021년에는 소련과 미국이 우주로 가기 위해 치열하게 경쟁했을 당시 1967년 우주 경쟁이 최고조에서 달했을 때 세운 139회라는 이전의 기록을 갱신했습니다. 2020년대의 우주 경쟁에는 미국, 영국, 유럽, 러시아, 중국, 인도, 튀르키예, 이란, 이스라엘 등 여러 국가들이 참여하고 있습니다. 2022년 상반기에만 72회의 성공적인 비행을 기록하며, 이러한 추세를 계속 이어갔습니다. 그리고 우주 경쟁은 더 이상 정부 주도 프로젝트가 아니라 많은 민간 우주 기업도 참여하여 대량의 투자 자금이 시장에 유입되고 있습니다.

새로운 로켓 기술로 인해 우주 발사가 크게 증가하고 있습니다. SpaceX는 2021년에 Falcon 9 미션 31개를 성공적으로 실행했습니다. 로켓 설계에 대한 새로운 접근 방식 덕분에 이전에 사용한 로켓 코어를 재사용하여 이러한 모든 미션을 실행할 수 있었으며, 이러한 실행을 지원하기 위해 새로운 Falcon 9 1단 로켓 2대만 도입되었습니다. 기업과 국가가 우주 발사의 신뢰성, 재사용성, 경제성 향상을 위해 계속 투자함에 따라 발사 횟수와 발사의 도달 범위는 계속 늘어날 것입니다.

이러한 발사를 지원하는 인프라도 함께 늘어나고 있습니다. 35개의 활성 우주 공항과 발사 시설이 있으며, 서브오비탈, 오비탈, 그리고 초지구 궤도 미션을 지원할 수 있습니다. 이러한 시설의 위치는 전 세계에 걸쳐 있으며, 모든 대륙과 13개국 이상에 분포해 있습니다.² 현재, 새로운 시설을 건설하고 있는 국가도 있습니다. 또한 이러한 시설에서 발사되는 로켓을 테스트하기 위해 추가 사이트가 사용됩니다. 이제 우주 산업에 참여할 흥미로운 시간이 되었습니다.

FAA는 미국 국토에서 발사하는 모든 로켓과 미국 시민이나 단체가 미국 외부에서 발사하는 모든 로켓을 규제하며,³ 다른 국가에도 유사한 규제 및 규제 기관이 있습니다. 기업은 적절한 엔지니어링 단계를 수행하지 않고 우주로 로켓을 발사할 수 없습니다. 중요한 단계 중 하나는 로켓 발사체를 테스트하고 성공 가능성이 높음을 증명하는 것입니다.

로켓 테스트는 로켓의 다양한 부품을 테스트하는 것으로 시작합니다. 엔지니어링 팀은 구조, 연료, 전자 장치를 구성하는 재료와 부품을 별도로 테스트합니다. 그런 다음 이러한 부품을 조립하고 서브시스템으로 테스트한 후, 마지막으로 완전히 조립한 상태에서 인수 테스트에 전면적으로 돌입합니다.

NI 제품은 발사체의 모든 측면에서 사용됩니다. 정적 및 피로 구조 테스트 플랫폼은 연료 탱크의 강도가 비행의 스트레스를 견딜 수 있는지 테스트하는 데 안성맞춤입니다. NI의 PXI 기반 모듈식 계측기와 자동화된 테스트 소프트웨어는 항공 전자 기기의 회로를 테스트할 수 있는 강력한 플랫폼을 제공합니다. NI의 LRU HIL 테스트 아키텍처는 다양한 테스트 사례를 생성하여 항공 전자 기기의 컨트롤러를 테스트하는 데 이상적입니다. 

여기서는 로켓 엔진 테스트를 중점적으로 다루지만, 대부분의 내용은 최종적인 전체 발사체 테스트에도 적용됩니다.

로켓 엔진 테스트는 모든 타입의 로켓 엔진 테스트에서 매우 중요하므로 FAA 규정을 준수하려면 이러한 테스트를 거쳐야 합니다. 그러나 테스트는 단순히 규정을 준수하는 것을 뛰어넘어 더 많은 가치를 제공합니다. NASA의 한 보고서는 로켓 엔진 테스트에 소요되는 시간과 엔진의 신뢰성 사이에 긍정적인 상관 관계가 있음을 보여주었습니다.⁴ 각 엔진 제조업체는 추가 테스트에 들어가는 투자 및 비용과 예상되는 테스트 이점 간에 어떻게 균형을 잡을지 결정해야 합니다.

로켓 엔진 테스트 스탠드는 홀드다운(hold-down) 스러스트 구조물, 추진체를 위한 지상 지지 장비, 냉각 장치, 배출 격리, 테스트 중 안전 및 작동 관리를 위해 필요한 자동화 등 지원 및 컨트롤 시스템을 제공함으로써 로켓 엔진을 지지하고 테스트하도록 설계된 구조물입니다. 로켓 엔진을 테스트하려면 엔진을 테스트 스탠드에 장착한 후 제한된 시간 동안에 발사합니다. 로켓 엔진 테스트 스탠드는 필수 홀드다운 스러스트 구조물, 추진체를 위한 지상 지지 장비, 냉각, 격리, 배출 기능을 제공해야 하며 테스트를 자동화하고 작동 및 테스트 중 안전을 유지할 수 있는 컨트롤 시스템이 있어야 합니다. 엔지니어는 로켓을 수직 또는 수평으로 장착할지 결정해야 합니다. 각 방향마다 이점이 있습니다. 수직 장착 엔진은 측정값과 보다 쉽게 상호 연관을 지을 수 있는데, 테스트 중 받는 힘이 비행 중에 발생하는 힘과 비슷하기 때문입니다. 그러나 수직 장착 엔진은 테스트 중 로켓으로부터 배출 장치를 멀리 배치해야 하는 문제가 발생합니다. 이 문제는 일반적으로 화염 분산기를 사용하여 해결합니다.

그림 1. 로켓 엔진 테스트 스탠드의 요소

배출 장치는 테스트 시설에 여러 가지 문제를 야기합니다. 배출 장치는 열 외에도 소음이 심하고 더러움을 발생시킵니다. 배출 장치에 수냉 시스템을 추가하면 엔진에서 열을 옮기는 쿠션의 역할과 주변 지역에서 소음과 오염물질을 줄이는 보호 장치 역할을 할 수 있습니다.

로켓 엔진 테스트에는 다양한 변형이 있습니다. 표준 해수면 테스트는 많은 추가 장비 없이 테스트 스탠드에서 수행할 수 있지만, 다른 테스트의 경우 특수한 테스트 환경이 필요할 수 있습니다. 예를 들어, 우주 공간의 위성에서 자세 제어를 위한 로켓 추력기를 테스트하려면 테스트 스탠드에는 엔진의 의도한 작동 조건을 복제할 수 있는 진공실이 필요합니다. 다른 테스트에서는 엔진 짐벌을 테스트하기 위해 열 진공실 또는 추가적인 기계 디바이스가 필요할 수 있습니다.

또한 테스트 스테이션은 엔진 개발 단계에 따라 달라집니다. 엔지니어가 엔진 성능의 역학 관계를 더 많이 포착하려고 하면 엔진 초기 개발 테스트에는 센서가 많이 추가될 수 있습니다. 비행 시작 전에 자격 또는 인수 테스트를 실시하는 테스트 스탠드는 적절한 작동을 확인하는 더 작은 신호 세트를 테스트할 수 있습니다.

로켓 테스트를 설계하는 엔지니어링 팀은 새로운 테스트 스탠드를 설계할 때 이러한 모든 잠재적 요구 사항을 고려해야 합니다. 로켓 기술이 현재처럼 빠르게 발전하는 상황에서 엔지니어는 향후에 필요한 테스트를 계획해야 합니다. 테스트 설계는 알려진 요구사항을 충족할 수 있을 만큼 강력해야 하고 시간이 지남에 따라 변화하는 요구사항을 충족할 수 있을 만큼 유연해야 합니다.

NI 엔지니어는 로켓 테스트 시스템을 설계하는 엔지니어와 30년 이상 긴밀하게 협력해 왔습니다. 이 기간에 신기술과 소프트웨어 기법이 도입되면서 아키텍처는 성숙해졌습니다. 관련 사용 분야의 모범 사례(제트 엔진 테스트, 풍동, 기타 대형 테스트 시설)는 로켓 엔진 테스트에 사용되는 시스템의 설계에 영향을 미쳤습니다. 로켓 엔진 테스트 아키텍처를 성공적으로 설계하기 위한 몇 가지 핵심 원칙이 떠올랐습니다.

로켓 테스트 시설은 테스트 스탠드를 하나 또는 여러 개 지원할 수 있습니다. 각 테스트 스탠드에는 다양한 서브시스템 또는 패드의 지원이 필요한데, 스탠드에만 사용되거나 테스트 시설 내의 여러 스탠드 또는 사이트 간에 함께 사용될 수 있습니다. 시설 전체의 지상 관제 시스템 관리자는 모든 패드와 테스트 스탠드를 결합하여 시설 리소스를 조정하여 운영 관리합니다.

그림 2. 로켓 테스트 시설 서브시스템

서포트 패드 컨트롤 시스템은 성능을 추적하고 향상시키는 측정 기능뿐만 아니라 컨트롤의 안정성을 제공해야 합니다.

로켓 테스트 사이트를 성공적으로 구현하려면 이러한 시스템 간에 신중하게 조정해야 합니다. 수년 간 주요 항공우주 시설에서는 이러한 시스템 간의 통신과 테스트 간 시스템의 변동성을 충족할 수 있는 유연성을 갖춘 설계 패턴을 제공하는 컨트롤 방식이 개발되었습니다. 테스트와 발사 시설을 모두 관리하는 항공우주 회사에서는 패턴의 많은 구성요소를 공유하여 테스트 대상과 발사 방법 간의 차이를 줄입니다.

이 아키텍처는 모든 테스트 스탠드와 패드에 공통된 시스템 설계 패턴을 사용합니다. 패턴은 각 시스템에 필요한 로컬 컨트롤을 제공하며 테스트 작업의 동기화를 위해 시스템 간에 정보를 공유합니다.

그림 3. 일반적인 컨트롤 시스템 설계 패턴

이 패턴에서 컨트롤 시스템은 이 문서의 뒷부분에서 설명하는 통신 프로세스에서 수신된 입력을 읽습니다.

스케일링 프로세스는 이러한 원시 단위를 서브시스템에 적합한 과학적 단위로 변환합니다. 스케일링 프로세스에서는 채널 여러 개를 채널 하나로 결합할 수도 있습니다. 예를 들어 모든 스러스트 부하 셀을 합해 단일 스러스트 값을 제공합니다. 또한 테스트 사이 또는 작동 중에 계측을 변경할 수 있기 때문에 스케일링 프로세스는 재구성 가능한 교정을 적용합니다.

알람 프로세스는 스케일링 프로세스에서 생성된 데이터 포인트의 출력을 평가하여 알람을 식별합니다. 알람은 즉시 테스트를 강제 종료하는 경고 또는 운영자에게 잠재적인 문제를 알리는 경고 등 여러 항목으로 분류될 수 있습니다. 알람 프로세스는 테스트 시퀀스의 성공적인 종료를 관리하거나 다른 시스템에 명령을 보내 이러한 동작을 관리할 수 있습니다. 테스트 운영자는 이 구조를 사용하여 비상 정지 또는 정상적인 종료를 설계할 수 있습니다.

테스트 진행을 방해하는 알람이 없으면 로직 프로세스는 읽기, 스케일링, 알람 프로세스의 값을 분석하여 다음 동작을 결정합니다. 예를 들어, 로직 프로세스는 액체 매니폴드의 온도가 밸브를 열어 유체가 파이프라인을 통해 흐르도록 하는 시점 (즉, Lox 매니폴드의 냉각)에 도달했음을 확인하여 다른 원격 서브시스템에 명령을 내리거나 시퀀스 프로세스에 밸브를 로컬로 열라는 명령을 전달합니다.

그런 다음 시퀀스 프로세스는 테스트 운영자가 개발하고 비행 요구사항 (시뮬레이션된 비행 컨트롤) 또는 발사/시설 요구사항 (시뮬레이션 발사 또는 공칭 테스트 작업)으로 정의되는 조건 (리미트, 경계, 운용 한계 속도)을 기준으로 정렬되어 타이밍이 지정된 이벤트로 결정되는 동작을 실행합니다. 간단한 동작은 즉시 실행될 수 있으며, 복잡한 동작은 순차적인 실행을 처리하기 위한 병렬 프로세스를 분리할 수 있습니다. 시퀀스 프로세스는 읽기, 로직, 알람 프로세스의 값을 입력으로 사용하고 필요에 따라 병렬 시퀀스 프로세스 출력을 업데이트합니다.

그림 3은 이러한 기능을 일련의 단계로 보여줍니다. 그러나 실제 적용 시 이 패턴을 사용하면 자체 스레드를 실행하면서도 주요 작동 오케스트레이션 스레드와 동기화되는 별도의 병렬 모듈을 허용합니다. 이렇게 하면 메인 스레드가 정지하여 동작이 완료될 때까지 대기하지 않고 일정한 속도로 실행됩니다. 컨트롤 시스템 루프는 일반적으로 제어되는 시스템에 따라 1 Hz~400 Hz 사이에서 작동합니다.

이 일반적인 설계 패턴은 모든 컨트롤 시스템에 적용할 수 있지만, 단순 시스템에서는 일부 요소가 옵션이거나 다른 시스템에서 처리될 수 있습니다. 예를 들어, 단순 모터 컨트롤러에는 알람 프로세스가 없을 수 있습니다. 대신, 모터를 제어하는 시스템의 출력을 기반으로 다른 시스템에서 알람 조건을 처리할 수 있습니다. 단순 시스템은 시퀀스 프로세스가 없을 수 있지만 대신 매우 기본적인 컨트롤 시스템의 로직 프로세스 또는 예를 들어 iDDS 또는 gRPC를 통하는 다른 컨트롤 시스템의 시퀀스 프로세스로 직접 제어됩니다.

그림 4. 통신 서비스

컨트롤 시스템은 통신 서비스를 통해 원격 명령과 원격 측정을 읽고 씁니다. 즉, 열리도록 밸브에 명령을 내리거나 서포트 패드를 제어하는 다른 원격 컨트롤 시스템에서 시퀀스를 시작합니다. 이러한 서비스는 메인 어플리케이션 내에서 직접 실행되기 보다는 백그라운드에서 실행되는 데몬 또는 마이크로서비스입니다. 입력 읽기 기능을 사용하는 대신 서비스를 사용하여 통신하면 메인 어플리케이션이 마이크로서비스의 지표를 모니터링할 수 있기 때문에 어떠한 문제도 메인 어플리케이션의 실행에 영향을 미치지 않습니다. 이렇게 하면 새로운 통신 인터페이스가 있는 새로운 디바이스를 사용할 수 있게 될 때 메인 컨트롤 루프에서 통신을 추출해 장비와 설정을 보다 쉽게 업데이트할 수 있습니다.

그림 4에는 통신 서비스의 예가 몇 가지 나와 있지만, 통신에는 더 많은 옵션이 있습니다. 시설 설계 팀은 시설에 맞게 사용자 정의된 통신 프로토콜을 설정하거나 시설 전체에서 사용되는 장비를 지원하는 표준 프로토콜을 선택할 수 있습니다.

새 장비를 구입할 때 중요한 고려사항 중 하나는 시설에서 기존 통신 서비스를 지원하는 것입니다. 사이트에서 통신 프로토콜의 수를 제어하면 소프트웨어의 개발 및 유지관리를 단순화할 수 있습니다. 서비스를 사용하면 새 통신 프로토콜이 허용될 때 프로세스가 개선됩니다.

그림 5. 통신 서비스 설계 패턴

각 통신 서비스는 디바이스와 프로토콜의 요구사항을 충족하도록 설계되어야 합니다.

일반적인 통신 서비스에는 몇 가지 공통적인 요소가 있습니다. 서비스의 핵심에는 하드웨어의 현재 상태를 추적하여 원하는 다음 상태를 결정하는 상태 머신이 있습니다. 예를 들어, 명령을 보내기 전에 디바이스를 초기화해야 할 수도 있습니다. 상태 머신은 디바이스의 초기화 상태를 추적하고 초기화를 요청한 다음 명령을 보내도록 요청합니다. 이 서비스는 단계가 타임아웃되거나 디바이스와의 통신이 끊어질 때와 같이 다른 네트워크 어플리케이션에서 모니터링할 수 있는 지표를 제공합니다. 이러한 지표는 다른 시스템에서 동작을 실행하도록 요청할 수 있습니다.

그림 6. 운영자 콘솔

하드웨어 인터페이스는 공급업체의 API를 사용하여 하드웨어와 통신합니다.

통신 인터페이스는 특정 포맷, 메타데이터, 암호화 또는 압축을 포함하는 프로토콜의 데이터를 패키지로 만듭니다. 일부 프로토콜에는 관리를 위해 상태 머신에 전달되는 핸드쉐이킹 또는 설정 관리가 필요합니다.

운영자가 접근할 수 있도록 각 컨트롤 시스템에는 운영자 콘솔이 하나 또는 여러 개 있을 수 있습니다. 컨트롤 시스템에서 혼동을 피하기 위해, 일반적으로 활성화된 컨트롤 콘솔이 하나만 있습니다. 이는 전용 컨트롤 콘솔이거나 컨트롤 중재 기능이 있는 콘솔일 수 있어 운영자가 컨트롤을 요청할 수 있습니다.

고려해야 할 설계 기능으로는 콘솔에서의 재구성 가능성이 있습니다. 테스트 사이에 또는 심지어 테스트 중에 테스트 요구사항이 변경되기 때문에 테스트 엔지니어는 이러한 콘솔에서 추가적인 데이터에 접근해야 하는 경우가 많습니다. 필요할 수 있는 데이터의 대부분은 통신 서비스에서 사용할 수 있으므로, 실제 소프트웨어 코드를 변경하지 않고도 사용자가 새 데이터 포인트를 구독할 수 있는 콘솔을 생성할 수 있습니다. 이렇게 하면 데이터가 필요한 엔지니어에게 유연성이 제공되고 소프트웨어의 변경으로부터 나머지 시스템이 보호됩니다. 예를 들어, 콘솔은 통신 서비스의 모든 데이터 채널을 구독하고 콘솔 사용자가 어떤 신호를 볼지 선택할 수 있습니다. NI는 NI G Web Development Software를 사용하여 Static Data Viewer를 생성할 때 이 설계 패턴을 사용했습니다.

마찬가지로, 설계자는 명령 신호를 설정 가능한 방식으로 운영자 콘솔에 노출할지 여부를 고려해야 합니다. 이렇게 하면 테스트 엔지니어는 소프트웨어를 업데이트하지 않고도 컨트롤 기능을 변경할 수 있어 빠른 속도로 실행되는 로켓 테스트 환경에서 생산성을 높일 수 있습니다. 이 기능은 입력 읽기 단계에서 컨트롤 시스템으로 데이터를 전달하는 통신 서비스에 설계되어야 합니다.

콘솔은 특정 컨트롤 시스템을 위한 전용 디바이스 또는 스크린이거나 다른 콘솔과 결합하여 운영자 스테이션이 될 수 있습니다. 운영자 스테이션은 한 위치에서 전체 테스트 스탠드에 대한 보기와 컨트롤을 제공합니다.

이 모두를 합쳐 놓으면 전체 구조가 나타납니다.

그림 7. 로켓 테스트 시설의 아키텍처

이 구조는 다음과 같은 이점이 있습니다.

• 각 시스템은 다른 시스템과 독립적으로 실행되므로 다른 시스템의 응답을 기다리느라 지연이 발생하지 않습니다.
• 독립적인 시스템으로서, 각 시스템은 다른 시스템에서 기술에 대한 결정에 영향을 주지 않고도 가장 적합한 기술을 사용할 수 있습니다.
• 시스템 전체에서 공통된 설계 패턴을 사용하면 하드웨어 및 소프트웨어 팀 모두의 개발 및 유지보수가 간단해집니다.
• 이 구조는 시설 확장에 맞춰 확장될 수 있으므로 테스트 스탠드 및 지원 시스템 수에 상관 없이 지원할 수 있습니다.
• 이 아키텍처는 모든 공급업체의 구성요소를 지원하며, 새로운 기술이 사용 가능하면 업데이트할 수 있습니다.

마지막으로, 완전히 조립된 로켓 테스트 시설은 그림 8의 이미지와 유사할 수 있습니다:

그림 8. 로켓 테스트 시설

이 문서에서 설명하는 구조는 로켓 테스트 시스템의 설계를 위한 설계 패턴을 제공합니다. 이러한 구조를 구현하기 위해서는 많은 엔지니어링 결정이 필요합니다. 이 문서에서는 팀이 설계 프로세스 시작 시 가장 중요한 측면을 고려할 수 있도록 아키텍처의 측면을 설명하고자 합니다.

아키텍처를 구현하는 방법을 결정할 때 가능한 한 초기에 고려해야 할 가장 중요한 항목은 다음과 같습니다.

시스템 지연 시간

각 서브시스템과 테스트 시설 전체에서 테스트 영역의 컨트롤 및 안전을 유지하기 위해 허용할 수 있는 최악의 지연은 무엇입니까?

시스템 전반의 지연은 여러 설계 결정의 결과입니다. 더 빠른 루프를 사용하면 한 시스템의 구성요소 하나에서 다른 시스템의 다른 구성요소로 통신 속도가 향상됩니다. 그러나 엔지니어는 시스템 간의 홉 수를 고려해야 합니다. 최종 타겟에 도달하기 위해 여러 시스템 사이에서 데이터를 전달해야 하는 경우에는 컨트롤 시스템 간에 데이터를 더욱 직접적으로 전달할 수 있는 경우보다 누적 지연이 더 커집니다. 설계를 결정할 때, 다른 시스템에서 직접 또는 시스템 간에 여러 번 복사하여 데이터를 어떻게 사용할 수 있는지 고려하십시오.

타이밍

시설 전체에 분산된 시스템의 타임 클럭은 다릅니다. 측정에서 얼마나 많은 타임 스큐를 견딜 수 있습니까?

대부분의 시스템은 로컬 디바이스의 시스템 클럭을 사용하여 측정에 태그를 지정합니다. 이는 여러 시스템 간에 데이터를 분석하는 경우 시스템 간에 데이터를 상호 연관시킬 수 있어 유용합니다. 일반적인 솔루션은 IEEE-1588 또는 유사한 프로토콜을 사용하여 모든 시스템에서 절대 시간을 제공하는 것입니다. 시간은 시설 관리자 시스템이 제공하거나 시스템에서 타임베이스의 GPS 신호에 의존할 수 있습니다.

프로세스 컴퓨터와 지상 시스템 사이의 데이터를 상호 연관시키는 방법도 고려해 볼 수 있습니다. 이 방법은 로켓 테스트에서는 상당히 간단하지만, 로켓이 발사된 상황에서는 지상 시스템과 로켓 사이의 연결이 끊어지기 때문에 더욱 복잡해집니다. 테스트 시스템은 발사 조건을 반복하기 때문에 테스트 스탠드를 설계할 때 이 점을 고려해야 합니다.

공유 리소스의 배포

어떤 서브시스템은 테스트 스탠드 간에 공유되고 어떤 서브시스템은 특정 테스트 스탠드에만 사용됩니까?

공유 리소스를 고려할 때는 리소스 복제 비용과 리소스 공유 비용이라는 두 가지 비용 간에 균형을 맞춰야 합니다. 극저온 탱크 시스템을 구축하는 데에는 상당한 비용이 발생합니다. 그러나 극저온 유체를 두 개의 별도의 테스트 스탠드에 연결하는 경우에도 상당한 비용과 복잡성이 발생합니다. 리소스를 공유하면 두 가지 작업을 실행하는 데 모두 리소스가 필요할 때 두 작업의 병렬 실행 기능을 제한할 수 있습니다.

경합 조건 관리

컨트롤 시스템의 명령 경쟁에서 공유 리소스를 어떻게 보호합니까?

여러 명령 시스템으로 제어할 수 있는 컨트롤 시스템은 통신 시스템 내에 규칙이 부족하기 때문에 의도하지 않은 동작을 수행할 위험이 있습니다. 예를 들어, 테스트 스탠드의 요청에 따라 밸브가 작동을 시작할 수 있지만, 두 번째 테스트 스탠드가 설정값을 덮어쓰면 두 스탠드 모두에서 치명적인 오류가 발생합니다.

설계 팀은 시스템에 있는 모든 명령 신호에 대해 적절한 잠금 절차가 마련되도록 시스템을 신중하게 검토하여 잠재적 경합 조건이 있는지 확인해야 합니다.

또한 경합 조건은 스토리지 시스템이 데이터를 가져오기 전에 데이터를 덮어쓰면 측정 데이터에 영향을 줄 수 있습니다. 즉, 가져오는 데이터가 의도한 데이터가 아닐 수 있습니다.

이중화

이중화 컨트롤이 마련되어 있어야 하는 시스템은 무엇입니까? 어떤 수준의 이중화가 마련됩니까?

이중화 센서, 배선, 수집 디바이스, 프로세서, 알고리즘, 전원 공급 장치 등 시스템 내의 여러 곳에서 이중화를 적용할 수 있습니다. 일부 항공우주 기업에서는 안전을 극대화하기 위해 시스템 전체에서 트리플 이중화를 필요로 합니다. 다른 기업에서는 가장 위험한 실패 지점을 식별하고 실패 지점에 이중화 작업을 집중합니다.

설계 팀이 시스템의 각 지점에서 선택할 수 있는 이중화 모델에는 여러 가지가 있습니다. 대기 이중화에서는 동일한 보조 유닛이 주요 유닛을 백업합니다. 수동 대기 (Cold Standby) 시스템에서 보조 유닛은 유휴 상태이며, 워치독이 주요 유닛에 장애가 있는지 확인할 때만 작동합니다. 상시 대기 (Hot Standby) 시스템에서는 보조 유닛이 전원을 켜지고 시스템을 활발하게 모니터링하지만, 워치독이 컨트롤을 보조 유닛으로 전환할 때까지 출력이 사용되지 않습니다. 이는 실패 시 가동 중지 시간을 단축할 수 있지만, 보조 유닛이 작동 중이기 때문에 보조 유닛의 안정성은 유지되지 않습니다.

모듈 이중화는 상시 대기 방식과 비슷하지만, 두 시스템 모두 병렬로 실행되며 시스템의 출력을 생성합니다. 어떤 출력을 사용할지 결정하는 투표 시스템 (Auctioneer 또는 Voter라고도 함)이 있습니다. 이 시스템은 컨트롤러 중 하나에 장애가 발생할 경우 충돌 없이 전송하도록 합니다. 이 모델은 2개보다 더 많은 컨트롤러로 확장할 수 있습니다. 이러한 예와 다른 예는 이중화 시스템 기본 개념에 관한 NI 백서에 나와 있습니다.

환경 요구사항

측정 장비는 어떤 환경에 노출됩니까? 측정 및 제어 장비를 보호하기 위해 필요한 추가 인프라는 무엇입니까?

추진 테스트 중 테스트 스탠드 또는 테스트 스탠드 근처의 장비는 극단적인 환경 조건에 노출됩니다. 갑작스러운 충격, 연속적인 진동, 높은 온도 등이 여기에 해당합니다.

테스트 사이에도 장비는 극단적인 환경 요인의 영향을 받게 됩니다. 높거나 낮은 온도, 습도, 염수 분무는 모두 테스트용 장비의 가용성에 악영향을 미칠 수 있는 위협입니다.

엔지니어는 테스트 스탠드의 환경 조건을 인식해야 합니다. 이 정보를 사용하여 시스템의 잠재적인 요구사항을 초과하는 장비를 선택하거나 설계해야 합니다. 이렇게 하려면 견고한 장비를 구입하거나, 균일 코팅과 같은 보호 장치를 추가하거나, 캐비닛이나 환경이 제어된 별도의 건물에서 장비를 보호해야 할 수도 있습니다.

네트워크 토폴로지

구성요소 장애 시 이중화를 포함하여 네트워크에서 데이터 전송을 위한 최적의 성능을 제공하는 네트워크 기술은 무엇입니까?

네트워크 토폴로지를 설계할 때 사용할 수 있는 옵션은 여러 가지가 있습니다. 시설 토폴로지를 성공적으로 만들려면 IT 인프라 팀과 테스트 엔지니어링 팀이 상세한 부분까지 논의해야 합니다. 테스트 팀은 데이터 대역폭, 지연 및 기술 요구사항을 설명해야 합니다. 네트워크 레이아웃을 계획하려면 IT 팀이 암호화, 레이아웃 및 이중화를 이해해야 합니다.

네트워크 설계 시 결정을 내릴 때 설계 팀은 이중화 모델을 결정해야 합니다. 이중화 모델에는 시설 전체에서 이중화 네트워크 케이블 배선, 빠른 확장 트리 프로토콜 (RSTP) 사용, 여러 배포 스위치 사용이 포함될 수 있습니다.

I/O 범위

측정 또는 제어하려면 어떤 신호가 필요합니까?

엔지니어링 팀이 직면하는 첫 번째 작업 중 하나는 테스트 스탠드에서 측정하거나 제어해야 하는 신호 리스트를 수집하는 것입니다. 신호를 문서화하는 동안 신호 타입, 위치, 분해능, 데이터 속도, 여기 요구사항, 안전 요구사항, 전압 및 전류 레벨을 나열해야 합니다.

이 정보를 사용하면 엔지니어가 측정 뱅크에 신호를 수집한 후 모든 신호에 액세스할 수 있는 적절한 하드웨어를 선택할 수 있습니다.

데이터 대역폭

테스트 중에 발생할 것으로 예상되는 데이터 양을 네트워크 토폴로지에서 처리할 수 있습니까?

컴퓨팅 디바이스, 스위치 하드웨어, 서브네트워크 아키텍처를 포함한 네트워크의 설계에 따라 네트워크를 통해 이동할 수 있는 데이터의 양이 달라집니다. 설계팀은 네트워크 구성요소를 신중하게 검토하여 시스템에 병목이 있는지 확인해야 합니다.

이론적으로 계산하면 시스템 설계에 지침이 될 수 있지만 네트워크 어플리케이션은 이론적 최대 데이터 속도를 달성할 수 없습니다. 데이터 오버헤드와 지연 시간이 네트워크의 전체 처리량에 영향을 미칩니다. 네트워크를 설계할 때는 이론적 한계보다 훨씬 더 낮은 데이터 속도를 유지하는 것이 좋습니다.

안전성

어떤 안전 시스템을 설치해야 합니까?

로켓 시설에는 많은 위험 조건이 있습니다. 시스템의 설계, 구현 또는 작동 시 실수가 있으면 치명적인 사고가 발생할 수 있습니다. 설계 팀은 연방 및 지역 법률에 의해 요구되는 안전 규정을 인식하고 있어야 합니다. 또한 설계 팀은 테스트 스테이션과 관련된 인력, 장비 및 영역을 법률이 보장하지 않는 범위까지도 보호하는 방법도 고려해야 합니다.

로켓 엔진의 전원 공급에 사용되는 가스 때문에 로켓 시설의 일부 영역은 위험합니다. 이러한 가스 중 일부는 완전히 격리될 수 없으므로 전기적인 점화로 인해 화재나 폭발이 발생할 수 있습니다. 이러한 상황을 방지하려면 위험 영역에 있는 모든 장비는 불꽃을 생성하지 않아야 하며, 안전해야 합니다. 이 문제는 전기 장비를 위험 영역 밖으로 이동해 해결할 수 있습니다. 전기적으로 제어되는 밸브를 위험 영역 밖에 배치하면 영역에 있는 유일한 장비는 밸브에서 멀리 떨어진 파이프입니다.

디바이스가 위험 영역 내에 있어야 하는 경우 해당 장비는 장비 공급업체에서 기본적으로 안전한 것으로 인증 받아야 합니다. 미국에서는 이는 Class 1 Div 1 인증에 해당합니다. 유럽에서는 가스 유형에 따른 ATEX 인증을 의미합니다.

디바이스가 위험 영역 밖에 있지만 위험 영역으로 신호를 보내는 경우, 디바이스에서 생성된 불꽃이 위험 영역으로 전달되는 것을 방지하기 위해 디바이스에는 내부 장벽이 있어야 합니다. 열전쌍 측정 계측기와 같은 하위 레벨 디바이스에도 디바이스의 전원 (예: 연결된 전원 공급 장치)이 위험 영역으로 전달되는 것을 방지하기 위해 내부 장벽이 필요합니다. 내부 장벽을 디바이스와 위험 영역 사이의 신호 경로에 부착하여 전압과 전류 스파이크를 모두 방지할 수 있습니다. 내부 장벽은 신호 타입에 따라 다르기 때문에, 열전쌍을 위해 설계된 장벽은 밸브 컨트롤러에 적합하지 않습니다.

인증

시설, 지원 시스템 및 테스트 스탠드에서 충족해야 하는 인증은 무엇입니까?

주민, 시설의 목적, 현지 법률, 로켓 장비의 목적에 따라 다양한 인증이 필요합니다. 예를 들어, 미국 공군 기지에서 실시하는 로켓 테스트는 모든 로켓 작업 전에 AFSPCMAN 91-7108 인증을 받아야 할 수도 있습니다.

테스트를 수행하는 데 필요한 인증뿐만 아니라, 인증은 테스트의 목적에 영향을 미칩니다. 테스트의 목적이 로켓 엔진을 사용할 수 있는지 인증하는 것이라면 테스트 스탠드 설계는 해당 인증서의 요구사항을 충족해야 합니다. 예를 들어, MIL-STD-8109는 테스트 중인 디바이스가 제품 사용의 예상 조건을 충족하도록 합니다. MIL-STD-20210은 300파운드 미만의 구성요소가 까다로운 사용 분야의 전기 및 환경적 요구사항을 충족하도록 보장합니다. 이러한 인증은 미국의 국방부가 테스트 중인 기술의 의도적 고객인 경우 필요합니다.

테스트 스탠드 및 지원 시스템이 있는 로켓 테스트 시설을 설계하는 것은 매우 꼼꼼하게 진행되어야 하는 대규모 프로젝트입니다. 본 문서에서는 일반적인 설계 패턴과 설계 프로세스에 대한 접근 방식을 제공하고자 합니다. 프로세스의 각 단계를 요약하는 것은 이 문서의 범위를 벗어나지만 설계 프로세스는 이러한 기본 단계를 따릅니다. 이 프로세스가 설계 팀의 능력을 초과하는 경우, 설계 프로세스에서 NI와 NI 파트너를 참여시키는 방법에 대한 정보는 다음 서비스 섹션을 참조하십시오.

시스템 식별

결과: 시설에 설계될 시스템 및 서브시스템의 블록다이어그램

시설 시스템을 배치하여 시작합니다. 시설의 현재 및 향후 요구사항을 기반으로 테스트 스탠드 및 지원 시스템 위치를 계획합니다. 시스템 간의 전송과 시스템 간의 연결을 계획합니다. 어떤 지원 시스템이 공유되고 어떤 시스템이 테스트 스탠드 전용인지 결정합니다.

시스템 요구사항 생성

결과: 시설에서 설계할 각 시스템 및 서브시스템에 대한 상세 요구사항

식별된 각 시스템의 요구사항을 문서화합니다. 업데이트 속도 및 통신 프로토콜을 포함하여 예상되는 입력 및 출력을 나열합니다. 필요한 성능을 포함하여 시스템의 예상 기능을 문서화합니다. 회사 내 어떤 기능 팀이 각 시스템을 설계할지 결정합니다.

시설 전체의 요구사항 확인

결과: 시설을 함께 연결할 시스템 및 인프라에 대한 상세한 요구사항

시스템 요구사항에 따라 해당 시스템을 지원하는 시설 시스템의 성능을 확인합니다. 모든 시스템 및 구성요소의 지연 시간 요구사항을 충족하기 위해 필요한 업데이트 속도를 문서화합니다. IT 팀과 협력하여 시스템의 요구사항을 충족하는 네트워크 인프라 요구사항을 파악합니다. 시스템에서 최악의 경우가 발생할 때 데이터 속도를 계산합니다.

기술 선택

결과: 시스템 및 시설 요구사항을 충족하는 기술 목록

시스템 및 시설 요구사항에 따라 문서화된 필요사항을 충족하도록 구축 또는 개발할 특정 기술을 확인합니다. 공급업체와 만나 사용할 수 있는 상용 기술을 파악합니다. 엔지니어링 팀과 협력하여 시스템에서 남아있는 간극에 대한 맞춤형 엔지니어링 방식을 파악합니다. 가능한 경우에는 시스템의 성능을 테스트하여 요구사항을 충족하는지 확인합니다.

통신 서비스 설계

결과: 시스템 및 시설 장비에 사용할 각 통신 서비스의 요구사항 및 구현을 문서화합니다.

시스템에 사용할 수 있는 기술을 잘 이해하고 각 통신 서비스의 요구사항을 문서화합니다. 각 서비스의 입력, 출력 및 처리를 확인합니다. 서비스의 완전한 구현에 필요한 전문 지식을 파악합니다.

시스템 컨트롤러 설계

결과: 시설의 각 시스템 컨트롤러에 대한 문서 작성

시스템 및 시설에 대해 선택한 기술에 시스템 요구사항을 적용합니다. 구체적인 성능 기준에 따라 원하는 입력, 출력, 기능을 문서화합니다. 시스템 컨트롤러를 구현하는 데 필요한 전문 지식을 확인합니다.

시스템 컨트롤러 및 통신 서비스 구현

결과: 각 시스템 컨트롤러와 시스템 간에 실행되는 코드

각 시스템 컨트롤러와 각 통신 서비스에서 실행되는 코드를 개발합니다. 요구사항 문서의 모든 변경사항을 문서화하고 해당 변경사항이 다른 시스템에 영향을 미치지 않는지 확인합니다. 각 구성요소가 문서화된 요구사항을 충족하는지 확인하는 유닛 테스트를 포함하여 적절한 엔지니어링 원리를 개발에 적용합니다.

시스템 컨트롤러 연결

결과: 컨트롤 시스템 간에 값 업데이트

시스템 컨트롤러와 통신 서비스를 연결합니다. 시스템이 예상되는 성능 범위 내에서 정상적으로 작동하는지 확인합니다. 구성요소, 서브시스템, 시스템이 연결되면 계속해서 유닛 테스트를 실행합니다.

시스템 성능 검증

결과: 각 시스템 구성요소, 시스템 및 상호 연결된 시스템의 성능 검증

전체 시스템이 설치되어 있는 경우, 시스템과 전체 시스템에 대한 전체 검증 테스트를 수행합니다. 요구사항을 검토하여 모든 요구사항이 충족되는지 확인합니다. 예상치 못한 동작을 개발자에게 보고하고 원하는 성능을 얻을 때까지 반복합니다.

운영자 스테이션 및 뷰어 생성

결과: 시스템을 제어하고 보기 위한 운영자 화면 및 스테이션

운영자 콘솔은 시스템과 함께 개발됩니다. 사용성 개선사항을 콘솔에 적용하고 최종 운영자 콘솔을 생성합니다.

로켓 테스트 아키텍처에서 사용할 수 있는 기술에 몇 가지 최신 발전 사항이 있습니다.

gRPC

gRPC는 어떤 환경에서도 실행할 수 있는 고성능 오픈 소스 프레임워크입니다. 원격 프로시저 호출 (RPC)을 기반으로 Google이 개발한 gRPC는 지난 5년간 시스템의 일부에서 데이터를 전달하는 방법으로 사용이 빠르게 증가하고 습니다. gRPC를 사용하면 클라이언트 어플리케이션은 다른 컴퓨터의 서버 어플리케이션에서 메소드를 마치 로컬 객체인 것처럼 직접 호출할 수 있습니다. 이렇게 하면 로켓 테스트 아키텍처와 같은 분산된 구조를 쉽게 생성할 수 있습니다. NI 소프트웨어 및 하드웨어 도구는 gRPC와 호환됩니다. gRPC 지원 리소스 및 호환성에 대한 정보를 확인하십시오.

iDDS

iDDS는 Rolls Royce와 MDS Aero가 제트 터빈 엔진 테스트를 위해 개발한 데이터 추상화 프로토콜입니다. 이 프로토콜은 네트워크에서 구독자가 사용할 수 있는 계측 노드에서 데이터를 수집하는 통신 서비스를 제공합니다. iDDS는 데이터 분산 서비스 (DDS) 백본과 OMG (Object Management Group) 표준을 기반으로 구축되었습니다. iDDS는 채널 메타데이터, 타임스탬프, 설정 및 상태 모니터링과 같은 측정 데이터를 포함하여 DDS 네트워크에서 계측 데이터의 패키지를 정의합니다. 디바이스 간 통신이 iDDS 모델 내에서 표준화되어 있기 때문에, 특정 제조업체의 기능을 추상화하면 신규 제공업체에서 제공하는 신기술을 사용하게 되는 경우에도 쉽게 장비를 교체할 수 있습니다.

NI는 변화하는 안전 요구사항, 새로운 센서, 시장에 요구되는 기술을 통합하여 로켓 엔진 테스트를 위한 맞춤형 하드웨어 및 소프트웨어 솔루션을 제공합니다. NI 소프트웨어는 맞춤형 테스트 솔루션, 리얼타임 데이터 시각화, 로깅, 자동화된 테스트 시퀀싱을 위한 도구를 제공합니다. 이러한 소프트웨어 솔루션은 강력하고 적응 가능한 플랫폼을 통해 데이터 분석, 시설 관리, 전체 테스트 효율성을 향상시킵니다.

NI PXI, NI CompactDAQ 및 NI CompactRIO와 같은 하드웨어 플랫폼은 극단적인 조건에서도 잘 견딜 수 있고 광범위한 신호를 지원하도록 설계되었으며 로켓 엔진 테스트 중 안정적이고 정확한 측정 및 제어 기능을 보장합니다. 이러한 견고한 모듈형 시스템은 분산 측정 및 로컬 처리 기능을 제공하여 테스트 정확도와 유연성을 향상시킵니다. 이전에 비해 더 짧은 시간 내에 더 많은 엔진을 테스트하는 방법을 알아보려면 NI의 로켓 엔진 추진 테스트 솔루션을 살펴보십시오.

• 로켓 엔진 추진 테스트 솔루션
• 로켓 추진력 테스트를 위한 NASA 데이터 수집 시스템 소프트웨어
• 테스트를 통해 로켓 개발 효율성 혁신

각주:

¹ https://arstechnica.com/science/2022/01/thanks-to-china-and-spacex-the-world-set-an-orbital-launch-record-in-2021
² https://www.go-astronomy.com/space-ports.php
³ https://www.ecfr.gov/current/title-14/chapter-III
⁴ https://ntrs.nasa.gov/api/citations/20050182932/downloads/20050182932.pdf

참고 문헌

• https://static.e-publishing.af.mil/production/1/ssc/publication/sscman91-710v3/sscman91-710v3.pdf
• https://www.atec.army.mil/publications/mil-std-810g/mil-std-810g.pdf
• https://nepp.nasa.gov/DocUploads/1F6AB74B-4517-4AD0-A34813268E75B8EB/MIL-STD-202.pdf