보잉의 Starliner 우주선의 다음 시험 비행을위한 승무원 모듈은 플로리다에있는 NASA의 케네디 우주 센터에있는 회사의 공장 및 처리 시설 내부에 있습니다. 크레딧 : Boeing
Boeing의 Starliner 승무원 캡슐 프로그램을 담당하는 프로그램 관리자는 금요일에 추가 검사를 통해 12 월 우주선의 첫 번째 조종되지 않은 궤도 시험 비행을 괴롭힌 우주선의 소프트웨어에 문제가 발견되지 않았지만 Boeing 엔지니어가 지상 시험 중에 지름길을 가졌다는 제안을 철회했다. .
Boeing은 Starliner의 Orbital Flight Test 중에 소프트웨어 오류 한 쌍을 놓쳤습니다. 하나는 우주선이 국제 우주 정거장과 도킹하는 것을 막았고 다른 하나는 지구로 돌아 오는 동안 캡슐에 치명적인 손상을 초래할 수있었습니다.
Boeing의 CST-100 Starliner 프로그램의 부사장 겸 관리자 인 John Mulholland에 따르면 Boeing이 지상에서보다 철저한 소프트웨어 테스트를 수행 한 경우 출시 전에 두 가지 오류가 모두 발생했을 수 있습니다.
멀홀랜드는 보잉 엔지니어들이 Starliner의 소프트웨어를 덩어리 단위로 테스트하고 각 테스트는 미션의 특정 부분에 초점을 맞추 었다고 말했다. 보잉은 전체 소프트웨어 제품군에 대한 엔드 투 엔드 테스트를 수행하지 않았으며 경우에 따라 비행 컴퓨터에 독립형 또는 에뮬레이터를 사용했습니다.
Mulholland는 금요일 기자와의 전화 회의에서“우리는 제품을 테스트하고 검증하는 데 필요한 규율에 다시 헌신하고 있습니다. "Boeing 팀은 Starliner 프로그램의 성공을 위해 노력하고 있으며 앞으로 나아갈 시간과 자원을 투입하고 있습니다."
12 월의 궤도 비행 시험 (OFT)은 올해 우주 비행사와의 첫 비행을 앞두고 우주 비행선에서 Starliner의 성능을 처음으로 시연하기위한 것입니다. OFT 임무를 괴롭힌 문제로 인해 보잉과 NASA는 조종사 임무로 넘어 가기 전에 조종되지 않은 두 번째 시험 비행을 계획해야 할 수 있습니다.
공무원들은 또 다른 자동 시험 비행이 필요한지, 스타 라이너가 다시 우주로 비행 할 수 있는지에 대해 결정하지 않았다.
보잉은 NASA와 계약을 맺은 Starliner 우주선을 개발했으며, 우주 비행사와 우주 정거장을 잇는 러시아 Soyuz 승무원 캡슐에 대한 단독 의존을 끝내고 자합니다. NASA는 Boeing에게 42 억 달러 계약을, SpaceX는 2014 년 Starliner 및 Crew Dragon 우주선 개발을 완료하기 위해 26 억 달러 계약을 체결했습니다.
The Crew Dragon은 2019 년 3 월 우주 정거장으로 조종사가없는 시험 비행을 성공적으로 완료 한 후 1 월에 캡슐의 비행 중 중단 기능을 시연했습니다. 우주 비행사가 탑승 한 첫 번째 승무원 비행에 대한 최종 준비가 진행 중이며 5 월부터 이륙 할 수 있습니다.
OFT 임무가 부적절한 테스트에 노출 된 후, Boeing의 엔지니어들은 우주선의 12 월 테스트 비행 중에 발견되지 않은 다른 오류를 팀이 놓치지 않도록 모든 Starliner 소프트웨어 라인을 조사하고 있습니다.
멀홀랜드는“Hindsight는 몇 가지 문제를 발견했지만이 팀이 지름길을 시도했다는 인상을주지 않기를 바란다”고 말했다. “그들은 그렇지 않았습니다. 그들은 풍부한 테스트를 수행했으며, 특정 지역에서는 분명히 갈 간격이 있습니다. 그러나 이것은 매우 재능 있고 강력한 팀입니다.”
소프트웨어 문제 중 하나는 Starliner가 12 월 20 일 케이프 커 내버 럴 (Cape Canaveral)에서 유나이티드 런치 얼라이언스 아틀라스 5 (United Launch Alliance Atlas 5) 로켓을 타고 우주로 올라간 직후에 명백히 드러났다. 캡슐의 미션 경과 타이머의 설정이 잘못되어 우주선이 Atlas 5의 Centaur 상단에서 분리 된 후 예정된 엔진 발사를 놓칠 수 있습니다.
Starliner 캡슐을 안정적인 궤도에 주입하고 우주 정거장을 찾기 시작하려면 궤도 삽입 화상이 필요했습니다. 온보드 타이머 설정으로 인해 자동 시퀀스가 실패한 후 휴스턴에있는 NASA의 Johnson Space Center에있는 지상 제어기는 Starliner 우주선이 궤도 삽입 화상을 수행하도록 수동 명령을 업 링크해야했지만 그 과정에서 선박이 너무 많은 연료를 태 웠습니다. 불충분 한 추진제를 랑데부하고 우주 정거장과 도킹하십시오.
휴스턴의 지상 팀은 궤도 삽입 화상 명령을 보내려고 할 때 Starliner와 안정적인 통신 링크를 설정하는 데 어려움을 겪어 기동 시작을 지연시킵니다. 보잉은 스타 라이너의 이틀간의 시험 비행 중 지상 팀들이 30 번 이상 추가로 우주선과 연결하는 데 문제가 있다고 밝혔다.
우주 정거장에 더 이상 도킹 할 수 없게되면서 미션 관리자는 Starliner 테스트 비행을 단축하고 12 월 22 일 뉴 멕시코 주 화이트 샌즈 스페이스 하버에 캡슐 착륙을 목표로 삼았습니다.
미션 타이머 문제가 발생한 후 Boeing 엔지니어는 다른 문제 영역을 찾기 위해 Starliner 소프트웨어 코드의 다른 세그먼트를 검토했습니다. 그들은 비행 전 테스트에서 놓친 또 다른 소프트웨어 오류를 발견했습니다. 이로 인해 우주선에 대기 중으로 다시 들어가기 직전에 두 요소가 분리 된 후 Starliner의 서비스 모듈이 크래프트의 승무원 모듈에 충돌 할 수있었습니다.
보잉의 스타 라이너 우주선은 12 월 22 일 뉴 멕시코의 화이트 샌즈 우주 항구에서 선박이 조종되지 않은 최초의 궤도 비행 시험에 착륙 한 후 보입니다. 크레딧 : NASA / Bill Ingalls
컨트롤러는 Starliner 우주선에 소프트웨어 패치를 전송하여 뉴 멕시코에 착륙 할 목적으로 deorbit burn을 수행하기 전에 잠재적 인 문제를 해결했습니다.
멀홀랜드 (Mulholland)는 금요일 Starliner 테스트 비행 이전에보다 광범위한 테스트가 소프트웨어 오류를 밝혀냈다 고 밝혔다.
엔지니어들은 임무 경과 시간 문제를 코딩 오류로 인해 Starliner 우주선이 Atlas 5 로켓의 비행 제어 시스템에서 잘못된 시간을 검색하게했습니다. Starliner는 터미널 카운트 다운에서 발사 차량에서 시간을 검색했을 때 Atlas 5의 발사 전 컴퓨터 시간에서 캡처 한 시간을 기준으로 내부 시계를 설정했습니다.
Bolin과 ULA 간의 공동 소프트웨어 시뮬레이션은 Starliner 우주선이 Atlas 5 로켓에 부착 될 때 발사 순서에만 초점을 맞췄습니다. 발사대에서 캡슐을 배치 한 시점에서 시뮬레이션이 종료되었지만 궤도 이륙 후 30 분 동안 발생하도록 예정된 궤도 삽입 연소 시간 동안 시뮬레이션이 계속되면 테스트 결과 타이밍 오류가 밝혀 졌을 것입니다.
멀홀랜드는“이러한 통합 테스트를 몇 분 이상 수행했다면 문제를 발견했을 것”이라고 말했다.
“저는이 임무 경과 시간의 민감도가 팀에 의해 인식되지 않았고 임무의 중요한 측면으로 여겨지지 않았기 때문에 이상적으로는 적어도 첫 번째 궤도 삽입 화상을 통해 그 (소프트웨어 테스트)를 실행했을 것입니다. 멀홀랜드는 말했다. “따뜻한 관점에서 볼 때, 우리는 오류를 발견하여 어떻게해야하는지 쉽게 알 수 있다고 생각합니다.
"첫 번째 궤도 삽입 연소 기간을 통해 ULA와의 통합 테스트를 실행했다면 타이밍이 손상되어 궤도 삽입 연소를 놓쳤을 것"이라고 그는 말했다. "우리가 그 시점에 도달했을 때, 소프트웨어는 화상이 여러 시간 전에 일어났다 고 믿었 기 때문에 화상을 입지 않았습니다."
멀홀랜드는 보잉 팀은 Starliner 임무 단계를 여러 조각으로 나누고 각 비행 구간에서 소프트웨어 테스트를 실행하는 것이 더 논리적이라고 생각한다고 말했다.
그는“런칭에서 도킹까지 한 번의 달리기를 할 때 컴퓨터에서 25 시간 이상 한 번의 달리기를하는 것”이라고 말했다.
멀홀랜드는“당시 팀은 다른 임무에 대해 여러 번의 테스트를 실시하기로 결정했다. "모든 팀이 의식적으로 지름길을 택하거나 그들이 적절하다고 생각하는 것을하지 않는 것은 문제가되지 않았습니다."
멀홀랜드에 따르면 보잉은 미래의 모든 스타 라이너 임무 전에 발사부터 우주 정거장과의 도킹, 도킹, 착륙 등 모든 이벤트를 포함하는 소프트웨어 통합 랩에서 더 긴 테스트를 수행 할 것이라고 밝혔다.
Mulholland는 더 철저한 테스트를 통해 재입국 전에 Starliner의 서비스 모듈을 안전하게 제압하는 데 필요한 잘못 구성된 소프트웨어를 발견 할 수 있다고 밝혔다. 소프트웨어 패치가 없으면 서비스 모듈 또는 추진 요소가 분리 후 승무원 모듈에 다시 충돌하거나 선박의 열 차폐를 손상 시키거나 악화 될 수 있습니다.
추진 컨트롤러는 Starliner의 deorbit 화상 후 및 재입국 전에 발생하는 분리 후 승무원 모듈에 다시 접촉하지 않도록 서비스 모듈에서 스러 스터 화상을 조정하는 역할을합니다.
서비스 모듈은 대기에서 타도록 설계되었으며 재사용 가능한 승무원 모듈은 열 차폐로 보호되는 지구로 내려갑니다.
Mulholland는 Starliner 서비스 모듈의 추진 컨트롤러는 다른 프로그램에서 사용 된 설계를 기반으로하며, 승무원 모듈에서 분리 한 후 서비스 모듈의 폐기 화상에 맞게 소프트웨어가 잘못 구성되었다고 Mulholland는 말했다. 추진 컨트롤러에 잘못된 "제트 맵"이 있는데 여기에는 서비스 모듈의 스러 스터 및 밸브에 대한 정보가 포함되어 있습니다.
Starliner는 두 개의 다른 제트 맵을 사용합니다. 하나는 전체 우주선이 연결되어있을 때 (승무원 모듈 컴퓨터가 추진기 발사를 명령 할 때) 그리고 다른 하나는 서비스 모듈이 분사 된 후 폐기 화상에 사용됩니다.
멀홀랜드는“집행 된 유일한 것은 통합 된 우주선을위한 하나의 제트 맵이었고 우리는 분리 후 서비스에 필요한 제트 맵을 놓쳤다”고 말했다.
그는 추진 컨트롤러에 대한 소프트웨어 테스트는 Starliner 우주선을 비행하려는 실제 컨트롤러가 아니라 에뮬레이터 또는 시뮬레이션 된 구성 요소를 사용했다고 말했다. Boeing이 소프트웨어 시뮬레이션을 실행할 때 실제 추진 컨트롤러는 뉴 멕시코의 서비스 모듈 스러 스터 테스트 발사에 사용되었습니다.
“추진 컨트롤러는 소프트웨어의 해당 섹션에 대한 자격 테스트를 수행했을 때 다른 테스트를 지원하는 외부에 있었지만, 에뮬레이터가 잘못되어 있고 올바른 제트 매핑이 없었기 때문에 문제가 발견되지 않았습니다. Mulholland는 자격 시험 중 "하드웨어가 실험실로 돌아 왔기 때문에 임무를 수행하는 동안 해당 시퀀스를 다시 실행하여 제트 매핑 문제를 식별하고 재진입을 시작하기 전에 소프트웨어 수정 프로그램을 업로드 할 수있었습니다."
Boeing이 구현하고있는 많은 개선 사항 중 하나는 적절한 하드웨어, 항공 전자 장치 상자 및 기타 구성 요소가 향후 소프트웨어 테스트에 포함되도록하기위한 요구 사항이라고 말합니다.
Mulholland는“실험실에 특정 항공 전자 장치를 설치하는 것이 중요하다면 실제로 자격 테스트를 실행하기 전에 해당 부품을 가지고 있어야합니다.
Starliner 시험 비행 중에 발생한 또 다른 문제는 NASA의 추적 및 데이터 중계 위성 네트워크와 선박의 통신 링크와 관련이 있습니다.
멀홀랜드에 따르면이 우주선은 12 월 이틀간의 시험 비행 중에 TDRS 네트워크에 37 번 고정하는 데 문제가 있었다고한다. Mulholland는 보잉 엔지니어들이 통신 중단 중 하나의 원인을 설명 할 수 있는데, 이는 설명 가능한 "false lock"조건으로 인한 것이라고 Mulholland는 말했다.
예상치 못한 통신 중단의 다른 36 건의 사례는 모두 플로리다에서 발사 한 지 몇 분 후에 Starliner의 첫 번째 지역 통과를 포함하여 북유럽과 러시아에서 발생했습니다. 지상 팀이 임무 경과 시간 오류 후 우주선 삽입 궤도 발사 명령을 보내는 데 어려움을 겪었을 때입니다.
Starliner 시험 비행에서 발생하는 문제를 조사하기 위해 독립적 인 검토 팀이 헌장을 마무리했습니다. 이번 조사 결과는 다음 3 월 6 일 금요일에 발표 될 예정이다.
그러나 멀홀랜드는 엔지니어들이 여전히 통신 문제를 조사하고 있으며 다음 주 무선 링크 중단의 원인에 대한 최종 평결은 기대되지 않는다고 말했다.
비행 문제에도 불구하고 Starliner 우주선은 안전하게 지구로 돌아 왔으며 착륙 후 검사 결과 다시 비행 할 수 있다고 Boeing은 말합니다.
멀홀랜드는 우주선의 열 차폐와 낙하산이 스타 라이너의 생명 유지 시스템과 마찬가지로 잘 작동했다고 말했다. 보잉은 또한 캡슐 도킹 시스템의 기능을 테스트 할 수 있었지만 우주선이 우주 정거장에 도킹되지 않았기 때문에 스타 라이너의 랑데부 및 항법 센서의 성능을 완전히 확인할 수 없었습니다.
플로리다에있는 NASA 케네디 우주 센터의 보잉 기술자들은 조종사가없는 OFT 임무를 다시 수행하든 우주 비행사가 탑승 한 첫 번째 시험 비행이든 다음 시험 비행을 위해 두 번째 Starliner 차량을 준비하고 있습니다.
스페이스 클럽(Space Club)