http://blog.naver.com/dapapr?Redirect=Log&logNo=110068951256 록히드마틴에서 아나로그 구형 모델을 가져다가 최신 엔진과 디지털로 재탄생 시킨것으로 알고있습니다.
미국은 중, 대형 디지털 프로그램은 갖고 있지만 소형이 없어서 KAI한테 프로그램 소스를 달라고 했답니다.
거절하자 미국이 엄청 난리를 쳤는데 소스 프로그램은 줄 수 없다고 아직도 버티는 것으로 알고있습니다.
우리나라가 개발한 프로그램은 소스가 3억라인이 넘는다고 합니다.
OFP는 지금 KAI쪽 직원이 파견나가 공동개발 형태로 지원중입니다.
T-50IQ의 OFP변경점 및 미국 T-X사업을 위한 OFP변경사업 때문입니다. 미군측의 요구사항에 따라 OFP전체에 대해 변경과 개량이 가해지고 있는데, KAI쪽 파견직원들이 록히드마틴에 상주하면서 본사와 록마를 연결해 작업중입니다.(현재 T-50의 칵핏 및 OFP자체가 미군이 요구하는 수준에 미달입니다.)
현재 T-50자체의 OFP가 자바기반으로 알고 있는데, 상대적으로 쉬운 언어로 개발하기 때문에 개발자 수급이 쉽고, 요즘 항전컴퓨터 연산능력과 기억용량이 향상되어서 효율이 떨어져도 자원빨로 밀어붙일 수가 있는데.
그런데도 최근 삽입할 프로그램및 개량객체들이 연산속도와 기억장치용량을 몇배로 처묵처묵하기 때문에...갈수록 부가적 연산량이 높아져가는 각종 전투지원모드들을 위한 컴퓨팅 자원배분과 용량이 한계에 도달하고 있습니다. 그래서 KAI는 요즘 자기네 독자적 API를 개발해서 몇몇 부분은 C언어를 사용해 프로그램 구동속도를 2배 가량 향상시키고, 용량은 10배 가량 덜쳐먹는 개량을 한 바 있습니다.
이걸 한 이유 자체가 미국이 요구한 T-X후보기종에 대응하기 위해 록마가 칵핏을 5세대 수준의 흔히 말하는 글래스 칵핏을 요구하기 때문이고. 당연히 각종 아날로그 계기판에 도시하던 각종 정보까지 알아보기 쉽게 수렴해 시현해야 합니다. MFD 2장에 각종 계기로 도시하고, 여전히 3세대수준에 머물던 HUD시현 정보량을 넘어서서...그런데 미션컴을 이제 와서 바꾸려면 예산은 때려치고, 절대 T-X사업기한에 맞출 수가 없죠.(물론 기존 미션컴 자체도 자바를 써도 될 정도로 넘치는 성능이었는데, 글래스 칵핏에 미군애들이 요구하는 각종 신규모드등을 추가하려니 빠와가 아주 딸립니다.)
이제 아날로그 계기는 거의 제거하고, MFD 3장과 HUD의 정보만으로 비행에 필요한 모든 정보를 도시하고, 전투에 필요한 정보를 시현하고 처리해야 합니다. 그래서 미션컴 여분 자원을 확보하기 위한 OFP최적화는 KAI가 했지만, 이렇게 해서 확보한 여분의 컴퓨팅 자원을 이용해 몇배는 급증한 정보시현을 위한 프로그램까진 소스코드고 나발이고 개털 없습니다-_-
이 부분에 대해서 외려 KAI가 록마한테 배우는 입장입니다. 해본 적이 없으니까.
미국이 소스코드를 달랬다고요? 이미 록마애들이 T-50OFP자체를 만지고 있습니다. 소스코드를 안 넘기고 말고 할게 뭐 있어요? T-X사업에서 요구하는 글래스 칵핏 구현 자체가 OFP전체를 떡 주무르듯이 개조하고 만지는 거구만.
KFX사업에 쓸게 없을까 하고 파견직원들이 뭐하나라도 건져가려고 노력할 정도입니다.
(F-35에서 쓰던 각종 프로그램이 삽입중입니다. 몇몇개의 심볼과 기호로 간략하게 도시하던 정보를 훨씬 더 정확하고 명시적인 방식으로 도시하게 됩니다. 도스시절 게임하고, 윈도우 시절 게임이 차원이 틀린것과 비슷합니다. 당연히 그래픽 자원도 훨씬 많이 쳐먹고요...)
OFP는 파일럿에게 최대한 직관적이고 빠르게 필요한 정보를 시현해주고, 각종 명령에 최대한 빠르게 대응헤 각종 연산을 수행해 전투에 필요한 정보를 생산해내야 합니다. 이 정보를 다시금 보기 편하게 도시해줘야 하죠. 이 부분은 솔직히 까고 말해서 미국이 세계 최고입니다. 유파하고 F-35 비행 시뮬레이션을 해보면 양자간의 유저인터페이스가 속된 말로 윈도3.1하고 윈도 7만지는 느낌처럼 십수년 차이가 납니다-_-; 하물며 KAI대 록마라면 뭐 뻔한 거 아닌가요?
적의 전투기, 공중조기경보기, SAM사이트, 레이더 사이트, 수상함등 각종 RF신호를 수신하고 분석해 식별하고, 해당 RF신호원들이 F-35를 발견할 수 있는 거리를 계산하고, 이 각종 중첩되는 반경들을 모두 연산해 들키지 않고, 비행할 수 있는 경로를 제시하고, 심지어 각종 무장을 이용해 공격하고 퇴피할 수 있는 최적의 경로까지 제시합니다. 이 정도 수준에 도달한 물건은 하나도 없습니다...유파의 경우 위협RF방위의 대략적인 방위만 알려주는 수준에 머물러 있습니다-_-; 파일럿에게 제공하는 정보는 물론 외부의 신호를 수집해 만들어내는 정보의 수준면에서도 십수년 차이가 납니다.
동종업계 다른 분이 들으면 언짢을수도 있겠으나, 그냥 편하게 쓰는 언어일뿐 신뢰성이 엄청 높은 언어는 아닙니다.
저 당시 시대면 느린 것은 둘쨰치고 고질병인 가베지 콜렉션도 잼병일텐데.. 쩝..
무슨 이야기냐하면 메모리를 쓰고 개방하고 쓰고 개방하는 것을 반복하다보면 찌꺼기가 많이 생기는데 스스로 정리를 잘 못해요.. 재시작으로 해결.. -_-;;
논문의 서론은 크게 볼 것이 없습니다. 한마디로 C로 하기 불편해서 java로 했다는 거죠.
저자들도 실제 임베디드에 올릴 때는 java를 C소스로 변환하는 기능을 이용해서 C 컴파일로로 바이너리 만들었다고 나오네요. 에휴..
그냥 전체적인 로직을 만들었다는 것에 의미를 두어야 겠네요.
첨언하자면 java 라는 언어자체의 문제가 아닙니다. java 야 훌륭하죠.. JVM 의 한계입니다. 물론, 요즘에는 많이 좋아졌습니다.
뭐, 발가락 조금 담갔다 뜨거워서 빼긴 했습니다만. 한국은 그 바닥이 그 바닥이라 워낙 뻔하니까요.(사람 등골 빨아 먹는데서 조금도 발전을 못했는데요 뭐.) C로 해서 불편한게 아니라, 사실 C를 제대로 다룰 수 있는 알짜배기 인력 많지도 않고 그걸 관리할 능력있는 회사가 국내에 존재나 하나요-_-죄다 5~6차까지 하청 내려서 단물이나 뽑아먹는 구존데. 하물며 KAI야 더 말해서 뭐하나요.
미국도 현재 ada는 사용자 구하기고 까다롭고, 당연히 사용자가 희귀하니 시간과 예산을 많이 퍼먹게 되어 거의 포기한 상황입니다. 그래서 어쩔 수 없이 타협한게 F-35의 C언어죠. 물론 이 이상으로 코스트와 시간싸움을 하는 민간항공사들은 그보다 더 큰 타협을 해서 에어버스나 보잉도 자사 민항기 OFP에 자바를 쓰고 있습니다.
그리고 보잉도 X-45C와 같은 무인기에 사용중이고, DDG-1000에도 쓰여지고 있죠.
이미 임베디드 컴퓨터 분야에도 자바가 꽤 널리 쓰이기 시작하고 있습니다. 물론 그냥은 안 쓰고, 독자적인 API를 통해 C언어 기반 라이브러리를 이용하는 식으로 약점을 보충해가며 쓰이고 있습니다.
작성일 : 15-12-17 17:11
조회 : 4,695
