자동 착륙 "Burana"
일반 독자들은 내가 모스크바 화성 실험 설계국에서 근무하면서 부란 작업에 참여했기 때문에 이 사건이 나의 관심을 피할 수 없다는 것을 알고 있다. 최첨단은 아니지만. 우리가 이 행사를 축하했던 우크라이나 호텔에서 연회가 있었는데, 이는 우리에게 정말 좋은 일이었습니다. 그리고 무인이지만 훨씬 더 긴 다음 비행에 대한 계획이 있었고 이러한 계획에 대한 작업이 있었습니다.
그리고 흐릿한 영원함이 있었고, 1993년에 프로그램이 종료되었습니다...
나는 아직 "부란" 자체에 대해 글을 쓰지 않았지만 이에 관한 장은 미완성 시리즈의 다음 장이 될 것입니다. 역사 재사용 가능한 유인 우주선 프로젝트. 그러나 나는 그 창조의 역사와 Energia 로켓에 대해서도 썼습니다. 그리고 이제는 "Buran"에 대해 글을 쓰지 않을 것입니다. 왜냐하면 이것은 블로그 게시물이 아니라 실제 기사, 어쩌면 하나 이상이어야하기 때문입니다. 하지만 우리 부서의 책임 영역을 보여 주려고 노력하겠습니다.
우리는 아마도 미국 셔틀보다 소련에게 확실한 유일한 우선순위를 제공한 일을 했습니다. 우리 부서는 Buran의 자동 착륙을 위한 알고리즘 및 소프트웨어 단지를 만들었습니다. 내가 아는 한 미국인들은 그러한 정권을 가지고 있지만 한번도 사용된 적이 없습니다. 그들의 셔틀은 항상 조종사에 의해 착륙되었습니다.
이제 내가 아는 한 승무원 없이 착륙하는 문제가 해결되었습니다. 결국 그들은 착륙합니다. 무인 항공기, 큰 것을 포함하여. 하지만 제 생각에는 여객기는 여전히 자동으로 착륙하지 않습니다. 그리고 저는 장비가 잘 갖춰진 비행장이 장비가 잘 갖춰진 여객기를 15미터 높이까지 끌어올릴 수 있다는 것을 확실히 알고 있습니다. 다음은 승무원입니다. 아음속 수준에서 Buran의 공기 역학적 품질이 당시 여객기의 약 절반 (4,5 대 8-10)이라는 사실로 인해 문제가 더욱 악화되었습니다. 즉, 배는 일반 스위핑 여객기보다 "철에 두 배 더 가깝습니다". 모양을 비교해 보면 놀라운 일이 아닙니다.
100톤짜리 거인의 자동 착륙은 매우 복잡한 일이다. 우리는 어떤 하드웨어도 만들지 않았고, 착륙 모드용 소프트웨어만 만들었습니다. 하강하는 동안 고도 4km에 도달하는 순간부터 착륙장에 멈출 때까지입니다. 이 알고리즘이 어떻게 만들어졌는지 아주 간략하게 말씀드리겠습니다.
***
첫째, 이론가는 고급 언어로 알고리즘을 작성하고 테스트 예제에서 그 작동을 테스트합니다. 한 사람이 작성한 이 알고리즘은 상대적으로 작은 작업 하나를 "책임"합니다. 그런 다음 하위 시스템으로 결합되어 모델링 스탠드로 드래그됩니다. 스탠드에는 작업 중인 온보드 알고리즘 "주위"에 장치의 역학 모델, 액추에이터 모델, 센서 시스템 등의 모델이 있습니다. 또한 고급 언어로 작성되었습니다. 따라서 알고리즘 하위 시스템은 "수학적 비행"에서 테스트됩니다.
그런 다음 하위 시스템을 모아서 다시 테스트합니다. 그런 다음 알고리즘은 고급 언어에서 온보드 컴퓨터의 언어로 "번역"됩니다. 이를 테스트하기 위해 이미 온보드 프로그램 형태로 온보드 컴퓨터가 포함된 또 다른 모델링 스탠드가 있습니다. 그리고 그 주위에는 수학적 모델이라는 동일한 것이 구축되었습니다. 물론 이는 순전히 수학적 입장에서 모델과 비교하여 수정되었습니다. 모델은 범용 대형 컴퓨터에서 "회전"합니다. 잊지 마세요. 당시는 1980년대였습니다. 개인용 컴퓨터는 이제 막 시작되었고 성능이 매우 낮았습니다. 당시는 메인프레임 시대였으며 두 개의 EC-1061이 있었습니다. 온보드 차량을 메인프레임 컴퓨터의 수학적 모델과 연결하려면 다양한 작업을 위한 스탠드의 일부로도 특수 장비가 필요합니다.
우리는 이 스탠드를 반자연적(semi-natural)이라고 불렀습니다. 결국 모든 수학 외에도 실제 온보드 컴퓨터가 탑재되어 있었기 때문입니다. 실시간에 매우 가까운 온보드 프로그램 작동 모드를 구현했습니다. 설명하는 데 시간이 오래 걸리지만 온보드 컴퓨터의 경우 "실제" 실시간과 구별할 수 없었습니다.
언젠가 저는 함께 모여 이 경우와 다른 경우에 대해 반자연적 모델링 모드가 어떻게 작동하는지 쓸 것입니다. 지금은 이 모든 작업을 수행한 팀인 우리 부서의 구성을 설명하고 싶습니다. 우리 프로그램과 관련된 센서 및 액추에이터 시스템을 다루는 포괄적인 부서가 있었습니다. 알고리즘 부서가 있었습니다. 그들은 실제로 온보드 알고리즘을 작성하고 수학 벤치에서 이를 해결했습니다. 우리 부서는 a) 프로그램을 컴퓨터 언어로 번역하는 것, b) 반자연적 스탠드(제가 일했던 곳)를 위한 특수 장비를 만드는 것, c) 이 장비를 위한 프로그램을 담당했습니다.
우리 부서에는 블록 제조를 위한 문서를 작성하기 위한 자체 디자이너도 있었습니다. 그리고 앞서 언급한 EC-1061 트윈의 운영과 관련된 부서도 있었습니다.
"폭풍우" 주제의 틀 내에서 부서와 전체 디자인 국의 결과물은 자기 테이프 프로그램(1980년대!)이었으며 이를 추가로 개발했습니다.
다음은 제어시스템 개발자의 입장이다. 결국, 항공기의 제어 시스템은 단지 온보드 컴퓨터가 아니라는 것이 분명합니다. 이 시스템은 우리보다 훨씬 큰 기업에서 만든 것입니다. 그들은 온보드 디지털 컴퓨터의 개발자이자 "소유자"였으며 발사 전 준비부터 착륙 후 시스템 종료까지 선박을 제어하는 모든 작업을 수행하는 많은 프로그램으로 컴퓨터를 채웠습니다. 그리고 우리의 착륙 알고리즘은 온보드 컴퓨터에서 컴퓨터 시간의 일부만 할당되었으며 다른 소프트웨어 시스템은 병렬로 작동했습니다(더 정확하게는 준병렬이라고 말하고 싶습니다). 결국 착륙 궤적을 계산한다고 해서 더 이상 장치를 안정화하고, 모든 종류의 장비를 켜고 끄고, 열 조건을 유지하고, 원격 측정을 생성하는 등의 작업이 필요하지 않다는 의미는 아닙니다. 에...
그러나 착륙 모드 작업으로 돌아가 보겠습니다. 전체 프로그램 세트의 일부로 표준 중복 온보드 컴퓨터에서 테스트한 후 이 세트는 Buran 우주선을 개발한 기업의 부스로 옮겨졌습니다. 그리고 선박 전체가 참여하는 풀 사이즈(full-size)라는 스탠드가 있었습니다. 프로그램이 실행 중일 때 그는 엘리베이터를 흔들고 드라이브를 윙윙거리는 등의 작업을 했습니다. 그리고 신호는 실제 가속도계와 자이로스코프에서 나왔습니다.
그런 다음 Breeze-M 액셀러레이터에서 이 모든 것을 충분히 보았지만 지금은 내 역할이 매우 미미했습니다. 저는 디자인 사무소 밖으로 여행을 가지 않았습니다...
그래서 우리는 풀 사이즈 스탠드를 살펴 보았습니다. 그게 다라고 생각하세요? 아니요.
다음은 비행 실험실이었습니다. 이것은 마치 Tu-154가 아니라 Buran인 것처럼 항공기가 온보드 컴퓨터에서 생성된 제어 입력에 반응하도록 제어 시스템이 구성된 Tu-154입니다. 물론 일반 모드로 빠르게 "복귀"하는 것도 가능합니다. "Buransky"는 실험 기간 동안에만 켜졌습니다.
테스트의 정점은 이 단계를 위해 특별히 제작된 Buran 프로토타입의 24회 비행이었습니다. BTS-002라고 불렸고, 동일한 Tu-4의 엔진 154개를 탑재했으며 활주로 자체에서 이륙할 수 있었습니다. 물론 테스트 중에 엔진이 꺼진 상태로 착륙했습니다. 결국 "상태에서" 우주선은 활공 모드로 착륙하고 대기 엔진이 없습니다.
이 작업의 복잡성, 더 정확하게는 소프트웨어-알고리즘 복합체의 복잡성을 이것으로 설명할 수 있습니다. BTS-002의 비행 중 하나입니다. 주 랜딩 기어가 활주로에 닿을 때까지 "프로그램 중"으로 비행했습니다. 그런 다음 조종사는 제어권을 잡고 노즈 기어를 내렸습니다. 그런 다음 프로그램이 다시 켜지고 완전히 멈출 때까지 장치를 구동했습니다.
그건 그렇고, 이것은 꽤 이해할 수 있습니다. 장치가 공중에 있는 동안에는 세 축 모두를 중심으로 회전하는 데 제한이 없습니다. 그리고 예상대로 질량 중심을 중심으로 회전합니다. 여기서 그는 메인 랙의 바퀴로 스트립을 만졌습니다. 무슨 일이야? 이제 롤 회전이 전혀 불가능해졌습니다. 피치 회전은 더 이상 질량 중심을 중심으로 하는 것이 아니라 바퀴의 접촉점을 통과하는 축을 중심으로 하며 여전히 자유롭습니다. 그리고 코스를 따른 회전은 이제 방향타의 제어 토크와 스트립에 있는 바퀴의 마찰력의 비율에 의해 복잡한 방식으로 결정됩니다.
이것은 매우 어려운 모드이므로 "세 지점"에서 활주로를 따라 비행하거나 달리는 것과 근본적으로 다릅니다. 왜냐하면 앞바퀴가 활주로에 떨어지면 농담처럼 아무도 더 이상 어디로 향하지 않기 때문입니다...
...테스트의 모든 단계에서 이해할 수 있거나 이해할 수 없는 문제가 우리에게 가져와 분석, 제거되고 수학적 입장에서 Zhukovsky의 BTS에 이르기까지 전체 라인을 따라 다시 전달되었다는 점을 덧붙일 것입니다.
***
여기요. 착륙이 완벽하게 이루어졌다는 것은 누구나 알고 있습니다. 1시간 비행 후 타이밍 오류는 1,5초였습니다! – 스트립 축으로부터의 편차는 XNUMXm이고 범위는 수십 미터입니다. 스트립 근처의 사무실 건물인 통제 센터에 있던 우리 직원들은 그 느낌이 말로 표현할 수 없을 정도라고 말했습니다. 물론 그들은 그것이 무엇인지, 얼마나 많은 것들이 올바르게 작동하는지, 올바른 관계에서 어떤 수백만 개의 상호 연결된 사건이 발생하여 이 착륙이 일어날 수 있는지 알고 있었습니다.
바이코누르의 유빌레이니 비행장 외곽. 이제 그것은 단지 비행장입니다. 나는 그곳에서 날아갔습니다. 그리고 에네르기아-부란 우주 수송 시스템의 운영을 위한 주요 활주로로 건설되었습니다. 당연히 Buran의 유일한 비행은 여기서 끝났습니다... Galina Iodko의 사진
그리고 나는 말할 것입니다 : "Burana"는 사라졌지 만 그 경험은 사라지지 않았습니다. 일류 전문가로 구성된 훌륭한 팀, 주로 젊은 직원이이 작업에서 자랐습니다. 그것으로부터의 책임은 팀이 어려운 해에 기초로 붕괴되지 않도록하는 것이었고, 그 당시에 Briz-M 상단 단계를위한 제어 시스템을 만들 수있었습니다. 더 이상 소프트웨어 시스템이 아니었고, 자체 탑재 컴퓨터가 있었고, 엔진, 커터, 다른 개발자의 인접 시스템 등 모든 탑재 된 기계를 제어하는 블록이있었습니다. 그리고 우리는 지상 기반 테스트와 상단 단계의 사전 실행 준비를했습니다.
물론 "Breeze"가 모든 KB에게 만들어졌습니다. 그러나 무엇보다도 소프트웨어 단지를 창안 할 때 매우 중요한 역할은 부란 (Buran) 사람들이 수행했습니다. 부란 (Buran) 서사시에 수십 가지 다른 프로필을 작성하여 수백 명의 전문가를 파견 한 위대한 사람들이었습니다. 그리고 현재 KB는 생존력을 입증했으며 많은 작업을하고 있습니다 ...
정보