F-2戦闘機開発についての誤解(その1)

航空自衛隊F-2戦闘機の後継となる次期戦闘機について、政府が外国と共同開発する方針を定めたようなんですが、これに関してF-2開発のことをデタラメに書いている記事がいっぱいあるので、ここはちゃんと書いておかないといけないなあ、と思ったブースカちゃんです。

まず今回は、日刊工業新聞の2020年5月6日記事

米と共同開発が有力な「F2」後継、“国産主導”のカギを握る長距離ミサイル 情報ブラックボックス化の懸念再び

そもそも英との共同開発案が浮上した背景は、F2開発の際に米が要となる飛行制御ソフト情報を開示せず、ブラックボックスで日本が苦労した苦い経験と歴史があるためだ。

嘘です。苦労してませんので。

当時のことを思い出しながらブースカちゃんが本当のことを書きますよ。

まず、F-2の開発はF-16C/D BLOCK 40の形態をベースラインにしたので、F-16C/Dの技術情報(要するに製造するための図面とか)が、ライセンス契約のもとで日本に開示されました。ジェネラル・ダイナミクス社(GD社)から送られたこの技術情報のことをTDP(Technical Data Package)と呼んでいました。
しかし、このTDPがなかなか来なかった。F-2(当時はFS-Xと言った)の基本構想図審査が終わったころでも、まだパッケージが揃ってないくらいだった。日本側はアメリカ側に何度も何度も何度も何度も要求したんだけど、GD社に言わせると米空軍のチェックがあるから遅れているんだ、とか言って先延ばしになってた。まあ最後には来たんだけど、遅すぎ。

で、飛行制御コンピュータを含めて、F-16が搭載する各種コンピュータのプログラムも、このTDPに入ってしかるべきなんです。(入ってたかどうか覚えてないけど、入ってたんじゃねえかな)
日本側は契約に基づいてF-16のライセンス権を持っており、プログラムも製造にあたっての「部品」なんだから、なんらかの記憶媒体(磁気テープとか)を使って提供されなければいけない。
しかし、F-2に搭載するコンピュータは日本製に決まってたし、F-2の形や大きさもF-16とは違うんだから、そんな記憶媒体を貰ったって仕方ないわけですよ。Windows PCにMac用OSのDVDを持ってきても、そんなもんはインストールできないのと同じです。

だけど、F-16用コンピュータ・プログラムの「ソース・コード」なら「参考」にできるかもしれないのです。
コンピュータにインストール(私たちの世界では「Load」とか言いますけど)するコードは、よく知られているとおり、2進数のバイナリ・コードですから、人間が読むことはできません。
一方、ソース・コードというのは、コンピュータにロードするバイナリ・コードの基になるもので、こちらはプログラマがプログラミング言語で書いたコード、つまり人間が読んで理解できるコードだからです。
しかし、ソース・コードは「製造ライセンス」に基づいて提供されるものではありません。
ソース・コードは「製造段階で必要」なものではありませんので、F-16製造用の部品としては扱われないからです。

で、当初はこのF-16の飛行制御用ソース・コードも、日本に開示する約束になってたんです。
日本は既にT-2CCV研究機で経験を積んでいるし、技術的な面からもF-16のソース・コードが必要だったわけではないのですが、くれると言うなら貰えばいいし、参考になればラッキーかな、っていう感じ。

ところが。

この時期、日米貿易摩擦は鎮まっておらず、アメリカの議会も日本にF-16の技術を渡すのに反対していました。さらには、日本航空電子がミサイル部品をイランに不正輸出したとかで、元社長らが逮捕(1991年7月)されたりしたことも受けて、結局「ソース・コード」の技術移転は行われないことになったわけです。

このことは「アメリカが約束を反故にした」っていうんで、センセーショナルに報道されました。
そのおかげで、アホな人たちは未だに「戦闘機には”ソース・コード”という重要なものがあるんだぜ」という、変な知ったかぶりをしているわけです。
自称「軍事ジャーナリスト」の人なんか「F-2には朝鮮戦争の頃のソース・コードが載っている」という凄いことを言ってました。ソース・コードという言葉の意味も知らない「軍事ジャーナリスト」です。びっくりです。

さて、これで日本側が困ったということはまったくありませんでした。日本側技術陣の本音は「渡さないんだったら最初からそう言えよ、めんどくせえな」くらいの感じです。
ここで飛行制御プログラムの「ノウハウ」について、素人ながら少し説明を加えておきますと、過去の開発経験が必要になるのは、操縦入力に対する機体の反応(ゲイン値)など「手加減」のような部分が多いのです。一方、プログラムの骨組みともいうべき「制御則(Control Law)」は、そういった「経験」に依存するものではないので、F-16のソースコードを見ようが見まいが、F-2の開発に与えるインパクトは小さいんですよ。

で、このへんの話について、一般の人から見れば、僕は当事者だったとも言えるわけですけど、飛行制御プログラムを担当していたわけではないので、関係ない素人だったとも言えるのです。なので、このへんの事情について本当の「当事者」に聞くとしたら、金沢工業大学のK先生に聞くといいです。

でも、これ30年も前の話なんだねえ・・・。

(・ω・) ←ジジイ

F-2戦闘機開発についての誤解(その1)」への45件のフィードバック

  1.  こんばんは。興味深く懐かしい話題ですね。当時の航空雑誌で”アメリカの嫌がらせ。T-2CCVの経験があるから大丈夫とはいえ、YF-16CCVの初飛行のようにCCV機は意図に反した軌道をすることがあり得るからソースコードは欲しかった”くらいの解説が並んでいた気がします。また、プラモ好きの航空ファンにとってハセガワから雰囲気モデルも出たカナード付きいかにもCCVなF-2のプランがいかにして潰れたのかを教えて欲しいです。当時の航空誌では”カナードなしでもCCV出来るから、重量、単純化、経費の問題で割愛した。でもすごいんだから、嘘じゃないよ”くらいの説明でガッカリしました。小生の妄想は”日本の技術力が足りず、米国がF-16CCVだのAFTIだのの秘密をくれなかったので実現できなかった”であります。F-2がカナード付きCCV並みの運動性能と言っても、CCVならではのバンク無し旋回とか、機首の方向とズレた飛行方向とか素っ頓狂な飛行振りのデモなんて見せてもらった覚えがないので信用できないのです。というか、MiG-29やフランカーのようなアクロも聞かないし(強度不足で禁忌なのかしら)。
    ま、F-2は試作機が出たころには冷戦が終わってソ連艦隊への対艦攻撃機という構想は無意味になりました。で、ソ連?CIS?ロシアからフランカー買わない?格安だよと誘われていた頃でした(フランカー欲しかった)。おまけに実用には問題山積だったので、一定迄の技術開発に留め、量産は損切してブルーインパルス専用機にすべきだったと思います。FCSの心配もなくなるし、ハードポイント回りの強度も問題も割安に解消できたでしょうし。自衛隊の戦闘爆撃機には諸々の淵源があるのでしょうが、F-86Fが浮いたので戦闘爆撃機として認めさせて既得権の橋頭保としここからF-1(T-2の派生という形を取ったがF-1が目的だった)に繋げF-2に至ると、航空誌か丸で読んだ覚えがあります。いわゆる専守防衛なら、戦闘爆撃機専門の部隊は作らないという路線もないではなかったわけで(内外を慮ってファントムに爆撃コンピューターと空中受油装置を搭載しなかったわけだし。EJ改で戦爆化したのはルサンチマン?)。
     連載、楽しみです。

  2. かつて、清谷氏とのツイッター上でのやり取りを拝見していましたが、清谷氏の言う「朝鮮戦争のデータ」とは何か、私なりに推測した事がありますので、この機会に書かせていただこうと思います。

    まず、「F-2には朝鮮戦争の頃のソース・コードが載っている」というのは、清谷氏の記述についての、JSF氏による読解ですね。
    http://obiekt.seesaa.net/article/168283827.html

    ですが、当の清谷氏の記述はそうした内容とは異なっています。
    https://kiyotani.at.webry.info/201010/article_9.html
    「またソースコードの開発では米軍がベトナム戦争のデータをくれなかったので、朝鮮戦争のデータを参考に開発されました。」
    「この話はF-2のレーダーの開発関係者に聞いた話です。」
    「レーダーを開発するのに単にハードウェアの知識だけでは開発できません。ソースコード、あるいは他のソフトウェアにしても現実の戦訓やそのデータ、ノウハウを参照にして開発されます。ですから実戦経験の豊富な米国やイスラエル、フランス製などのレーダーが信頼されているわけです。それは彼らのアセットですから、第三者においそれとは渡してくれません。」

    そして、松宮元空将の手記が引用されていますね。(ブースカちゃん氏も解説されていましたが)
    https://kiyotani.at.webry.info/201801/article_8.html
    「我が国にはフィールドデータが存在しなかったこと、つまり空戦で何機を相手にして、相手機がどの辺で攻撃してくるとかの実戦に基づくシナリオが無かった」
    「このシナリオがないとソフトウェアは組めずに、漠然とした「他目標処理」という要求にならざるを得ない。」

    では朝鮮戦争のデータとは何かという事ですが(清谷氏は問われても答えませんでしたが)、朝鮮戦争での航空部隊の日報であると私は考えます。米軍の記録は30年後に公開されるようなので、ベトナム戦争時の日報は、F-2開発時は公開されていません。

    レーダーの要求仕様を検討する第一歩として、空戦のシナリオを想定する必要があるということですね。空戦に参加する機種と機数、編隊の構成、速度、高度が、シナリオのベースになるでしょう。F-2開発時は、自衛隊側はこの空戦シナリオを想定せず、漠然とした要求仕様のままで発注したため、三菱電機が空戦シナリオを想定しなければならなかった、ということではないかと推測します。

    空戦シナリオを想定するにあたって、何の資料も無ければ的外れになってしまいますから、入手可能な資料として、朝鮮戦争での日報を参考にしたのでしょう。機体の性能は時代によって大きく変わりますが、しかし機数や編隊の構成は参考になるはずです。速度や高度、索敵距離、交戦距離などを時代に合わせて調整して、空戦シナリオを想定したのではないでしょうか。

    1. 基本的にはFlint_Lockさんの認識で正しいんですが、清谷さんの言った「ソースコードの開発では米軍がベトナム戦争のデータをくれなかったので、朝鮮戦争のデータを参考に開発」というのは完全にデタラメで、その根拠として「この話はF-2のレーダーの開発関係者に聞いた話です。」というのは、清谷さんが嘘をついているか、その「開発関係者」がデタラメを吹き込んだか、あるいはその「開発関係者」なる人物がただの法螺吹きである可能性が高いと思います。
      同種のデタラメは前間孝則さんの本にも書かれていて、「F-2のソースコードは零戦のデータに基づいて作られたという話を、戦闘機開発関係者から聞いた」というのを読んだことがあります。開発関係者を名乗って、専門知識皆無の「評論家」たちに法螺を吹いて回っている人物がいるのかもしれません。
      さて、Flint_Lockさんのコメントを読んで、この話はもうちょっときちんと詰めておく必要があると感じましたので、次回のエントリに書くことにします。

  3. 考察していただいて、有難うございます。

    松宮元空将の手記にある、「このシナリオがないとソフトウェアは組めずに」という箇所の「ソフトウェア」は、コンピュータープログラムを指しているのではなく、要求仕様を策定する工程を指している、という意味のことをブースカちゃん氏は説明されていましたよね。(それで合っているでしょうか?)

    その説明で、自分は理解を進めることができました。

    清谷氏の記述について補足ですが、こうありました。
    「ぼくの朝鮮戦争云々に関してのソースは電気の下請けでFCSにかかわっていた人物ですよ。」
    https://kiyotani.at.webry.info/201801/article_8.html

    私は今の所、その人物の発言内容は虚偽だと判断される理由が分からないですが…

    1. 清谷さんと三文字さんの麗しいウンコの投げ合い、改めて眺めました。
      ここでは、両者とも戦闘機(航空機)というシステムがどのように成り立っているかという、超基本的な理解を欠いていることがわかりますが、清谷さんが「ソースコード」とはなにか、を知らずに書いていることが、なにより致命的だと思います。
      松宮さんが書いたことの解説や、FCS関係者と称する人物の言がおかしいことを含めて、次回以降に書くことにします。エントリが2回くらいに分かれるかもしれません。

  4. こんな資料が、三菱重工のサイトで公開されていました。

    「次期支援戦闘機“XF-2”の開発,三菱重工技報 Vol.33 No.3(1996)」

    開発スケジュールや開発体制の図も、掲載されていました。
    解説していただく時の資料として活用していただけたらと思います。

    1. これはすんごく懐かしい記事ですね。
      https://www.mhi.co.jp/technology/review/pdf/333/333154.pdf
      神田さんは亡くなりましたけど、設計チームのチーム・リーダでした。設計チームでいちばん偉い人です。
      亀山さんはあまり接する機会がなかったですけど、飛行制御関係で、サブ・リーダを務めてらっしゃいました。
      小山さんは日米間技術移転とかプロジェクト管理などを中心に担当され、のちにサブ・リーダになられましたね。北大のラグビー部出身。
      川崎さんは、開発初期には油圧操縦系統のとりまとめもしてましたけど、設計管理とかプロジェクト管理とかを担当されました。
      主にこのへんの面々が、設計チームの司令塔のような仕事を担われたので、この記事を担当されたということですね。
      で、ブースカちゃんは川崎さんの下にいたのです。
      ( ^ω^ ) ナツカシー

  5. ブースカちゃんさんは、開発現場のど真ん中にいらしたんですね。
    当事者の方の紹介を聞くと、無味乾燥に見えていた資料が、生き生きとした情景として立ち現れてくる感じがします。解説の合間に、当時の様子などをぜひお聞きしたいです。

    何だか変なことを言うようで申し訳ないのですが、資料で使われている「ソースコード」という用語は、「中心的な役割のソフトウェア」という意味で使われているように思えるのですが、どうでしょうか。

    1. そうですね。
      記事中の「この飛行制御システムの中心となっているのが,ソースコードと呼ばれるコンピューターのソフトウェアであり」という書き方も、多くの誤解を招いた要因のひとつかもしれませんね。
      なにもここで「ソースコード」という言葉を持ち出さずに、「コンピュータ・ソフトウェア」と書けば誤解を招かないと思いますが、当時既に「ソースコード」という言葉だけが独り歩きして人口に膾炙しており、ここでF-16技術移転の話題に触れざるを得ないため、あえて「ソースコード」と書いたんじゃないかなあ、という気がします。
      あと、開発当時の様子なんですが、今から思うと落ち着いていましたねー。
      開発なんてどう転んだって修羅場なんですが、その後の開発のほうが「修羅場」感は強かったです。
      あくまで「今にして思えば」なんですが、ある意味で良い時代でした。
      お金もあったし。(このへんは別の機会に触れます)
      ( ^ω^ )

      1. そういえば、FS-X開発で僕の上司だった川崎さんは、のちのP-X/C-X開発では三菱重工のP-X/C-Xプログラム・マネージャになられました。
        そのとき僕は川崎重工のほうでP-X/C-X設計チームにいたんですけど。
        ( ^ω^ )

  6. 川崎氏とのご縁は、会社を移っても続いたのですね。(プログラム・マネージャというのは、F-2 では小山氏が担った役割でしょうか。)

    記事を読むと、開発管理について、従来の日本流の開発手法から変更した事に触れていますね。私の想像ですけれども、あいまいさを残して柔軟に変更を行っていく手法から、各段階での目標を明確に定義していく手法に変わった、というようなことでしょうか。

    川崎重工のP-X/C-X設計チームでも、その新たな管理手法を用いたのでしょうか。(ブースカちゃんさんが川崎重工に移られたのは、そういった理由もあるのでしょうか?)

    記事では、日米の「関係者間の相互信頼が高まり、一体感が醸成されてきた」とあります。その点について、松宮元空将の手記(「軍事研究」とは別の物)には、真逆のような認識が述べられています。

    FS-X(F-2)支援戦闘機の開発と教訓  松宮 廉
    https://jbpress.ismedia.jp/articles/-/9170

    (あまり大っぴらには言えませんが、私は下記のサイトで読みました。)
    https://web.archive.org/web/20171105182456/https://blogs.yahoo.co.jp/midway_naval_battle/25759335.html
    https://web.archive.org/web/20171105182531/https://blogs.yahoo.co.jp/midway_naval_battle/25759476.html
    https://web.archive.org/web/20171105182606/https://blogs.yahoo.co.jp/midway_naval_battle/25759656.html

    三菱重工のチームと、松宮氏とで、認識の違いはどうして生じたのだろうと思います。

    お聞きしたいことが色々と浮かんできますが、今後のエントリを楽しみにしています。

    1. 「三菱重工のチームと、松宮氏とで、認識の違い」というのは、日米担当者間の関係の話でしょうか。
      この点については、松宮さんと設計チームでは、相手が違うということなんですよ。

      設計チーム内では、日本の技術者がアメリカ人技術者たちと一緒に仕事をするんですが、アメリカ人技術者との関係はとても良好で、彼らは本当に真面目に、良い飛行機を作ろうと一緒に頑張ってくれました。アメリカ人技術者のリーダーはF-16XLの主任エンジニアだったトビー・ベンジンガーさんでしが、社内会議の席上などでも、しばしば「協力できることはなんでもするから、できることがあれば遠慮なく言ってくれ」と言ってくれて、実際に彼らの態度は非常に協力的でした。
      しかし
      話のレベルが技術移転など国益にかかわる問題は、設計チームの中で話し合われることではなくて、日米政府間(自衛隊と米軍間)での交渉です。松宮さんの出ておられたTSCなどは、設計を検討する場所ではなく、日米政府間の駆け引きが行われる会議体なのです。
      こちらの場面では、いつもアメリカが無茶な要求を出してきて、常に日本政府側が無理を飲まざるを得ないような、腸の煮えくり返るようなことばかりでした。
      ですから、日米間の関係は良好だったのか険悪だったのかという話は、そのレベルによって大きく違うんです。

      ちなみにブースカちゃんがP-X/C-Xへ行ったのは、単にブースカちゃんが「面白そうだから僕も仲間に入れて」って言って、紛れ込んでしまっただけです。深い理由はありません。
      ( ^ω^ )

  7. 開発に携わった日米の技術者の間では、ノウハウを相手方に渡さないように、といった姿勢は見られなかったということでしょうか。
    ベンジンガー氏の発言は、たとえば「契約上ソースコードは提供できないけれども、機体制御のノウハウは提供できるから聞いてほしい」という意味にもなるでしょうか?

    “F-16XL Toby Bensinger” で検索してみましたら、F-16XL の話題を扱う掲示板で、開発関係者の方達が会話していました。
    http://www.f-16.net/forum/viewtopic.php?f=23&t=9952&sid=375da165917622d63d7cdac88685bea6&start=15

    “johnwill” さんは、F-16XLの構造飛行試験のリーダーで、Bensinger氏と親しかったようです。
    「私は日本で1年間半、岐阜ABで構造飛行試験に従事しました」とのことで、Bensinger氏とは、日本では入れ違いになってしまったとか。

    1. 設計チームでは、日本人技術者とアメリカ人技術者が入り混じって働いていましたが、その配置は、基本的に所属する会社の作業分担に基づいています。
      ですから、飛行制御プログラムを作る設計室の技術者は、三菱重工の人たちですので、そこにGD社のノウハウは入りません。
      ベンジンガーさんの言う「できることは」というのは、当然おっしゃるとおり日米合意の枠内に限られるます。
      ベンジンガーさんは空力弾性が専門だったはずですが、たとえばフラッターの解析方法に、こんな方法を使いたいが、それは有効だろうか?というような課題であれば、彼の経験から「こういう方法でこんな失敗をしたことがあるよ」というようなアドバイスをもらうことができただろうと思います。
      しかし、その経験を裏付けるような技術資料(試験データとか)のようなものを彼個人が提供することは、日米合意の枠外になってしまうので、できないわけですね。
      こういう日米技術者の話についても、覚えている具体的なエピソードを、そのうち書き残しておきたいと思います。
      (・ω・)

  8. ご返答ありがとうございます。
    自分の知識が不足しているからだと思うのですが、下記の点がよく分からないでいます。

    >飛行制御プログラムを作る設計室の技術者は、三菱重工の人たちですので、そこにGD社のノウハウは入りません。

    飛行制御プログラムも、GD社が開発したのですよね。三菱重工とGD社の間で技術援助契約が結ばれており、機体の開発ではGD社の技術者が援助するが、飛行制御プログラムに関してはソースコードの提供のみで(提供は中止されたが)、技術者による援助は行わないことで合意していた、ということでしょうか。

  9. 飛行制御プログラムは、まったくGDがタッチしていません。
    全てゼロから日本人技術者だけによって書かれたものですよ。
    GDからは一切技術情報の提示はなく、逆に日本側もアメリカ側には一切技術を公開していないのです。

  10. 私の文章が説明不足でしたが、「F-16の飛行制御プログラムはGD社が開発した」という文意でした。日米間の技術援助契約と技術移転契約によって、F-2の機体の開発ではGD社の援助を受け、開発成果はGD社に技術移転されるが、飛行制御プログラムは、そうした援助や技術移転の対象外となっていた、ということでしょうか(ソースコードは提供されるはずでしたが)。

    ちなみにF-2の火器管制システムのソフトウェアやソースコードは、米国には提供されたのでしょうか。

  11. 「飛行制御プログラムは、そうした援助や技術移転の対象外」
    端的に言うとそういうことです。
    あと、火器管制システムについては機体とは別に三菱電機が開発を受託したのですが、これもアメリカへは出してないです。
    なお、火器管制システムのソフトウェアというのは、火器管制レーダの信号処理プログラムです。こんなものに朝鮮戦争もベトナム戦争もないんです。

  12. 三菱電機が開発したAESAレーダーの、アンテナや送受信部は米国へ技術移転されたが、信号処理については技術移転の対象外、ということでしょうか。

    信号処理に実戦のノウハウが関係するかどうかですが、第4.5世代戦闘機で実用化された「センサー融合」機能の開発に関して、こんな記事がありました。

    F-22やユーロファイターで開発中の、センサー融合について、1999年の記事(自動翻訳)
    https://www.flightglobal.com/sense-from-confusion/26605.article
    ——————————————————————–
    センサーフュージョンは、F-22およびタイフーンのコックピットの設計における重要な要素です。次のステップは、すでに米英合同ストライク戦闘機(JSF)のコックピットの設計に取り入れられています。

    そのような進歩は一夜にして起こるものではなく、大西洋の両側で、概念を証明し、センサー融合の中心にあるアルゴリズムを実証するために空飛ぶテストベッドが使用されています。彼らは、センサーフュージョンが戦闘機で 実際にテストされるまでに、数百時間の経験を蓄積します。

    FTBはカリフォルニアのエドワーズ空軍基地に配備され、戦闘テストF-22で運用され、ネバダ州のネリス空軍基地に配備され、レッドフラッグ戦闘演習を観察します。「レッドフラッグを使用すると、高いターゲット密度をリアルタイムで確認し、システムのストレスを確認することができます」とローウェル氏は語ります。
    ——————————————————————–

    空軍の大規模演習の中で試作機の飛行試験を行い、センサー融合のシステムに負荷をかけて機能を確認する、という事のようです。
    レーダーの信号処理に関しても、平時の試験環境では想定していないような状況が、実戦では起きうるのではないでしょうか。

  13. AESAレーダーというのは、独立したモジュールを多数組み合わせて一つのレーダー・システムを構成しているわけですが、FS-X開発後にそのモジュールをアメリカへ有償開示したということはあったようです。
    僕は電気屋さんではないので、レーダー信号処理の詳細までは専門的知識がないのですが、レーダー信号処理機のレベルで実戦を想定するとしたら、最新のECM(電子戦)技術への対抗を考慮するとか、そういうレベルの話です。

    その記事中にある「高いターゲット密度」というのは、レーダーの信号処理でどうこうする話ではなく、レーダーを含めた各種センサーで得た情報を整理する機能の話ですので、たとえばミッション・コンピューターの能力と機能(すなわち演算能力や処理プログラム)に関わってくると思います。
    そして、どれくらいの「高いターゲット密度」を想定するかは「具体的な」シナリオに基づく必要があるというのが、松宮さんの言っておられることだと思います。
    また、その「想定」には、必ずしも実戦の経験は必要なく、むしろ想定する戦闘様相と仮想敵の能力などを、新しい情報に基づいて検討分析した結果でなくてはなりません。

    アメリカが1970年代にベトナムで戦ったときのデータ(なんの?)が手に入らなかったからと言って、2000年代の日本周辺有事のシナリオが描けないわけではないし、むしろベトナム戦争とは全く違った作戦様相を想定しなければならないのです。

    これは余分な話ですが、F-35戦闘機は中東やヨーロッパでの戦闘を想定シナリオにしているらしい設計なので、日米による対中国作戦にはまったく不向きな代物です。

    1. 余分な話のついでに加えておきますと、航空自衛隊の次期戦闘機に対する要求性能は、報じられている限りでは、当然ですが対中国作戦を想定シナリオに持っているのが明らかで、F-35では足りていない部分も、できるだけカバーしようという意図が感じられます。
      決して十分ではないでしょうけど。

  14. (長文になりましたが、ご了承ください)
    「その「想定」には、必ずしも実戦の経験は必要なく、むしろ想定する戦闘様相と仮想敵の能力などを、新しい情報に基づいて検討分析した結果でなくてはなりません。」
    「アメリカが1970年代にベトナムで戦ったときのデータ(なんの?)が手に入らなかったからと言って、2000年代の日本周辺有事のシナリオが描けないわけではないし、むしろベトナム戦争とは全く違った作戦様相を想定しなければならないのです。」

    これは、用兵者としての知識と経験の蓄積がある自衛隊が、シナリオを想定する場合のことですよね。清谷氏が「FCS関係者に聞いた」として書いているのは、用兵者としての知識と経験を持たない機器メーカーが、シナリオを想定する必要に迫られた場合のことではないでしょうか。

    F-2のレーダー開発においては、自衛隊の要求仕様はあいまいで、自衛隊は三菱電機にシナリオを提供しなかったようです。作戦様相を検討する参考資料も提供されないまま、三菱電機はシナリオを想定せざるを得なかったと仮定します。

    たとえば攻撃機が戦闘機と協調しながら、攻撃任務を行うシナリオでは、どのような編隊の構成になるでしょうか。日本の旧海軍航空隊では、戦闘機を二手に分け、攻撃機の近辺に位置する直掩隊と、飛行時間にして5分程度先行する制空隊とで編隊を構成しています。

    攻撃隊を迎撃する敵部隊は、どのような行動を取るでしょうか。太平洋戦争では、正面から迎撃する場合もあれば、攻撃隊の帰路の半ばで背後から攻撃する場合もありました。

    三菱電機がシナリオで多様な状況を想定するにあたって、せめてもの入手可能な資料として、旧海軍航空隊の戦闘詳報を参考にしたということも、あり得ないことではないのではないかと私は思います。(より現在に近い実戦の資料になるほど有用ですが)

    「どれくらいの「高いターゲット密度」を想定するかは「具体的な」シナリオに基づく必要があるというのが、松宮さんの言っておられることだと思います。」

    そうした具体的シナリオによって「ターゲット密度」が想定されて、要求仕様が策定され、信号処理システムが設計、試作されるわけですよね。F-22では、試作されたシステムが予定通りの機能を発揮するかを確認するために、システムを実機に搭載して、大規模演習の中で飛行試験が行われています。

    実戦のシナリオで想定される状況は、大規模な演習であっても部分的にしか再現できないのではないでしょうか。たとえば、敵味方の航空機や地上部隊がミサイルを使用する状況で、信号処理システムがどのように機能するかは、大規模演習での飛行試験では再現できず、ミサイルの飛行はシミュレーションを併用すると思います。

    米軍は、過去の実戦において信号処理にどのような問題が発生したかを、分析していると思います。その分析結果は、その後の信号処理システムの設計において、活用されているのではないでしょうか。

    実戦で明らかになったシステムの欠陥の実例としては、1988年の米国のイージス艦によるイラン旅客機の撃墜事件があります。誤射が起きた要因として、特殊な状況において旅客機と戦闘機の判別が困難になるというイージスシステムの性能上の制約と、イランの水上艦艇と交戦中に旅客機が接近してきたことによるヒューマンエラーとが、挙げられています。

    実戦の状況で頻発するヒューマンエラーを、システムによって防止するにおいても、実戦を分析してノウハウを蓄積することが必要なのではないでしょうか。

    (F-35の想定シナリオの話は、とても興味が惹かれました。そうした指摘は、初めて目にしました。)

  15. 三菱重工であれ三菱電機であれ、設計にあたって自ら用兵シナリオを想定することはありません。また、具体的なシナリオを、自衛隊が民間企業に提供することもありません。直接設計に必要ないからです。
    シナリオを想定するのは自衛隊の仕事で、それを基にした要求を技術研究本部が具体的な要求性能として企業に示し、企業は技本の要求を満足するシステムを設計製造するのです。
    設計構想を詰めていく過程で、要求性能にあいまいな部分(たとえば「多目標対処を可能とする」とか)があって、設計を進めるうえで不十分であれば、その部分を明確化するために、技術研究本部は自衛隊と調整を図り、その結果をもって企業と調整します。
    松宮さんが言っているのは、ここで自衛隊が持っているシナリオに十分な具体性が欠けていた、ということです。
    ですから、開発のいかなる過程においても、企業側が勝手にシナリオを描くということはあり得ず、企業は技術研究本部に指示された「基本要求」を満たすことが契約の履行条件です。

    民間企業が自らシナリオを想定する場面は、防衛庁の要求に基づく開発においてではなく、将来事業の提案などのケースがあります。そういう場合は、あり得るシナリオを企業が仮定し、それに対する自社技術でのソリューションを提案します。

    レーダーの信号処理について言うと、たとえば前に挙げた電子妨害対抗の技術などでは、その対抗手段が本当に敵の妨害技術に対して有効であるかどうかは、机上検討だけでは必ずしも十分でない場合があるでしょう。
    こうした部分についても、必要なのは朝鮮やベトナムのデータ(なんの?)などではなく、最新の脅威に関する技術情報の収集や、研究試作による技術の確認などです。

    ヒューマンエラーの防止についても、やはり朝鮮やベトナムのデータは関係なくて、幅広い事例を含む一般的な研究や、自己の運用経験に基づいて、設計に反映されます。なお、この分野について、技術研究本部(現在の防衛装備庁)には、第一研究所に人間工学研究室があります。

  16. ブースカちゃんさんが指摘されていることは、「自衛隊の持つシナリオには十分な具体性が欠けており、当初の要求性能にはあいまいな部分があったが、技術研究本部が自衛隊と調整を図り、さらに企業と調整することで、要求性能は明確化された。要求性能の明確化は、技本と自衛隊が担う。」ということでしょうか。

    松宮氏の「FS-X(F-2)支援戦闘機の開発と教訓」から、関連個所を引用します。
    ——————————————–
    「また、トピックスの最後のところで御説明しました機体およびレーダー関係の不具合とその対応ですが、試作までを担当した開発の責任者としては、後輩諸君に誠に申し訳ないことをしたと思って深く反省しています。

    我々が基本設計から試作までにもっと技術的に詰めておけば、このような問題は生じなかったであろうとまでは申しませんが、もっと技術的に詰めておくべきであったのは事実です。

    特にレーダーについては、運用を想定した実環境下での技術的要求事項を明確にして製造会社に要求する必要がありましたし、製造会社はそれを踏まえた設計、試験、評価をすべきであったということも大きい反省点の1つです。」
    ——————————————–
    この箇所は、要求性能は明確化されないままだったことを意味すると思うのですが、どうでしょうか。

    「ヒューマンエラーの防止についても、やはり朝鮮やベトナムのデータは関係なくて、幅広い事例を含む一般的な研究や、自己の運用経験に基づいて、設計に反映されます」

    実戦において装備を使用すれば、平時では得られないようなヒューマンエラーの事例が得られるのではないでしょうか。
    ロシアは、シリア内戦において各種の装備を実戦使用して、データを収集している、と指摘されています。

    1. 「要求性能は明確化されないままだったことを意味する」
      機体の設計チームは直接レーダーの開発に関わっておらず、三菱電機さんがどの時点でどのような点を不足としていたかまでは、私も知ることができません。
      しかし、レーダーも開発の各段階で細かく防衛庁の審査を通過している以上、設計を進めるために必要なレベルに明確化された要求は、その各段階までに技術研究本部から示され、それらをクリアしながら設計が進められたということです。
      具体的に例えれば、「多数機を同時に追尾できること」という曖昧な要求では信号処理プログラムの仕様書は書けないよね、という問題に対して、「多数機とは戦闘機5機を想定する」などの定量値を、防衛庁側が明文化して会社側に伝えるというようなことです。
      しかし、そういった要求は「特にレーダーについては、運用を想定した実環境下での技術的要求事項」として「明確」ではなく、「結果として不十分であった」と松宮さんは考えており、「我々(技本と自衛隊)が基本設計から試作までにもっと『技術的に』詰めておけば」という文章になっているわけです。
      ここでも、やはり三菱電機が運用シナリオを考える、というような話ではありませんし、朝鮮やベトナムのデータも関係ないのです。FS-Xは、50年代の朝鮮半島や70年代のベトナムとは、まったく違った戦場で、まったく違う相手と戦うのです。
      どんな時代でも、レーダーの探知距離は長いに越したことはないし、分離識別能力は高いに越したことはありません。それらにどういう要求を課すか、というのは、過去のデータがどうこうではなく、その時代の技術レベルで実現可能、かつ、その戦闘機に必要な水準です。

      「機体およびレーダー関係の不具合」というのは、これとは別の話になるのですが、上述したように、FS-Xでは機体の開発とレーダーの開発が別々の契約として別々の会社に発注されたため、三菱重工も三菱電機も、機体とレーダーのインターフェイスに関わる問題については、十分に対応できなかった、という反省が込められています。
      実際に運用試験で問題が発生しても、機体側の問題なのかレーダー側の問題なのか、技術研究本部が技術的に検討していくためには、両社それぞれと別々に作業せねばならず、大きな支障になったということです。
      これは三菱重工や三菱電機が責任逃れをしたということではなく、どちらか片方だけでは相手側の設計について詳細がわからないため、できることが限られてしまうのです。(同じ三菱グループでも、別々の会社が別々に防衛庁と契約しているわけなので、情報は直接やりとりできません)
      この反省から、その後のP-X哨戒機の開発では、東芝で設計製造するレーダーも含め、「次期固定翼哨戒機」として川崎重工が主契約者の責任を負っています。こうしておけば、機体とレーダーのインターフェイスに関わる問題でも、川崎重工が責任を持って対応できるからです。

      「実戦において装備を使用すれば、平時では得られないようなヒューマンエラー」というのも、ある種のドグマだと思います。
      もちろん、生死を賭けた場面では思わぬエラーをする、ということもありますが、機械設計の観点においては、そうしたエラーも含めて、内外の長年の経験で包括できるものです。
      有名な例では、T-2CCVが離陸時に異常な横揺れを起こしたケースがあります。これは、実際の飛行においては、パイロットの操縦入力がシミュレータでの場合よりも過敏・過剰になり、意図しない不安定運動を招いたというものです。
      これは「エラー」ではありませんが、人間の関わる部分はシミュレーションだけでは必ずしも十分ではないことがある、という事例です。(わんわんモード問題と呼ばれました)
      これと同様のことを「実戦と訓練」という話に置き換えると、実戦では相手の戦力がまったく予想外である、とか、実戦では将兵のメンタルがやられてしまう、とかいう話のレベルなので、装備品の設計においてできることは、平時のエラー対策以上のことはありません。

      ちなみに、ヒューマンエラーを見越した設計になっていない例として、過去にオスプレイの話を書きました。
      https://booskanoriri.com/archives/2729
      これなども、有事だから起きたという話ではなく、航空機設計者が当然懸念するであろうエラーがなぜか対策されておらず、その理由も技術的には納得するのが難しい、という話です。

  17. 例えとして出されている「多数機とは戦闘機5機を想定する」についてですが、松宮氏の手記にはこうあります。
    「我が国にはフィールドデータが存在しなかったこと、つまり空戦で何機を相手にして、相手機がどの辺で攻撃してくるとかの実戦に基づくシナリオが無かった。このシナリオがないとソフトウェアは組めずに、漠然とした「多目標処理」という要求にならざるを得ない。」

    ここでの記述は、「具体的なシナリオを持たない限りは、多目標処理を定量値として性能要求にまとめることはできない」ということを意味するのではないでしょうか。
    ですので、技本が「多数機とは戦闘機5機を想定する」ことは、具体的なシナリオを持たない限りは不可能なのではないでしょうか。

    そして、技本が「漠然とした「多目標処理」という要求」をしていたということは、審査においても、審査の基準として定量値を用いることはできず、漠然とした基準を用いることになるが、それで構わないと防衛庁は判断していた、ということも意味するのではないでしょうか。

    オスプレイについてのエントリは、以前に読ませていただきました。
    防衛装備の設計において、実戦の経験は不要だとされる立場は、自分はまだ納得できないでいます。下記の説明は、いかが思われますか?

    「バトルプルーフ」
    https://www.weblio.jp/content/%E3%83%90%E3%83%88%E3%83%AB%E3%83%97%E3%83%AB%E3%83%BC%E3%83%95
    「武器・兵器が実戦で使用され、その性能や信頼性などが証明されること。
    高性能を誇る新兵器であっても、実戦における苛酷な環境や不意の出来事など、様々な要因により、兵器が設計された平時において算定されるカタログスペックが発揮できない事が多々有る。そのため、バトルプルーフされた性能はその兵器の真の能力を表しているとして高い信頼を受け、より高性能であったはずの兵器を押しのけて採用されるような事も少なくない。また、バトルプルーフで明らかになった問題点を克服する改良が加えられる事によって、信頼性を高める事も出来る。」

  18. ご紹介いただいた「バトルプルーフ」という記事は関賢太郎さんがお書きになったもので、専門的な解説でもなんでもなく、たぶん「戦争ゲームの設定」の話だと思いますので、現実世界の話に持ち出されても困ってしまいます。
    「兵器が設計された平時において算定されるカタログスペックが発揮できない」という記述がありますが、そんな「カタログスペック」という仕様書は存在しません。

    書かれた関さんは、実際の軍用航空機のモデルスペックをご覧になったことがあるかどうか知りませんが、そこに書かれているのは「実戦では発揮できない」などということが起きる類の内容ではありません。
    実戦で発揮できない性能というのは確かにあって、よく知られている例で言うと、ベトナムにおけるレーダー誘導ミサイルの命中率が、試験で得られた期待値よりも大幅に低かった、ということがあります。
    こうしたことは、なにも「実戦の経験がない」から起きるのではなく、最新の技術動向がつかめていなかったり、将来の戦闘様相の予測が完全にできないことから起きるものです。

    Combat Proven というのは、兵器メーカーが商品を売り込む際の謳い文句でもあり、それはそれで結構なのですが、それは設計者が新しい戦闘機を「設計」するために必要な技術情報とは直接関係がないのだということを、繰り返して説明しております。

    >技本が「多数機とは戦闘機5機を想定する」ことは、具体的なシナリオを持たない限りは不可能
    そんなものは多ければ多い方が良いに決まっているので、それをどこまで妥協できるのか、できないのか、というのが、用兵者側の判断です。これが具体的なシナリオに基づいていないのでは困る、というのが松宮さんの言っていることですね。

  19. 「兵器が設計された平時において算定されるカタログスペックが発揮できない」という話が、実際にどれくらい馬鹿々々しいか、ちょっと具体的に書きます。

    戦闘機のモデルスペックに「最大離陸重量25t」と書いてあれば、それは重量25tまでを想定した設計、試験が行われていることを示し、平時においては25tを超える運用は禁止されます。
    しかし、実際の有事や緊急事態に当たっては、この最大離陸重量を超える運用が行われることも珍しくありません。

    僕が昔話した一式陸攻のパイロットは、どこかの島を脱出する際に、詰める限りの人間を詰め込んで離陸した、滑走路はぎりぎりだった、と言っておりましたが、明らかに最大離陸重量を超えていたでしょう。
    逆に、平時は25tだけど、有事だから23tまでしか駄目です、などという現象は起こり得ません。

    また、最大速度 2.0M@8,000ft(標準大気)とあれば、それは2.0Mまでを想定して設計されているということですが、戦闘時であればこれを超過する速度で飛行することもあり得ますし、その実例もあります。
    最大荷重7.3Gという戦闘機が、墜落回避のために12~13Gの荷重がかかってしまった例もありました。

    しかし、戦争ゲームなどでは「青軍兵士の行軍距離は4km/h」とか「ミサイルの命中確率は50%」などの値が、キャラクターの「仕様」として設定され、それが「実戦ステージ」では低下するなどの仕掛けによって、疑似的に実戦のリアリティを演出することはよくあると思います。
    こうした話と、実際の工業製品である実在兵器の仕様の話が、最近増えてきた「評論家」のような人たちの間では、まったく混同されているように思います。

  20. >そんなものは多ければ多い方が良いに決まっているので

    戦闘機のレーダーの空対空モードは、10種類前後のサブモードに分かれますが、サブモードごとに探知距離、走査範囲(角度)、最大探知数、最大追跡数、などが異なる設定となっています。

    走査範囲(角度)が広いほど、一回の走査にかかる時間が長くなります。最大追跡数が大きいサブモード(TWS)では、探知距離は短くなり、走査範囲(角度)は狭くなり、走査時間は長くなります。このように、各パラメーターはトレードオフの関係にあります。

    長距離において使用する探知専用(追跡できない)のサブモード(RWS)や、近距離で使用する一機のみ追跡するサブモード(ACM)など、操縦者は状況によってサブモードを切り替えて使用します。

    設計段階で各パラメータを設定するに際して、空中戦の具体的なシナリオに基づいて検討しない限りは、最適解を割り出すことはできないはずです。

    Lockheed Martin 公式の、F-16C/D Block50 のレーダーのマニュアルです。
    http://ffw08.weebly.com/uploads/3/0/4/7/30476526/radar_air-to-air_modes

    遠距離の Range-While-Search(RWS)、中距離の Track-While-Search(TWS)、近距離の Air Combat Mode(ACM) のサブモードがあり、さらにサブモードに分かれます。

  21. >各パラメーターはトレードオフの関係
    そのとおりです。
    ですから、それをどこまで妥協できるのか、できないのか、というのが、用兵者側の判断です。これが具体的なシナリオに基づいていないのでは困る、というのが松宮さんの言っていることですね。
    それは朝鮮戦争もベトナム戦争も関係ないですよ。

  22. 具体的なシナリオに基づいて検討しなければ、パラメーターの設定が最適化されているかどうか、判断する基準は持てないはずです。
    例えば、最大追跡数が10で探知距離が50キロ、最大追跡数が8で探知距離が60キロ、どちらの設定を選ぶかということです。
    具体的なシナリオに基づいて検討しなければ、どちらの設定が適しているかが分かりません。これは、どこまで妥協できるのか、という事とは異なっています。

  23. >具体的なシナリオに基づいて検討しなければ、パラメーターの設定が最適化されているかどうか、判断する基準は持てないはずです。
    そのとおりです。
    ですから、その具体的なシナリオに基づいてどちらの設定が適しているかを判断するのは、運用者側であって、そしてそれは朝鮮戦争やベトナム戦争とも関係がありません。

  24. 松宮氏の手記は、自衛隊において具体的なシナリオは作成されなかったことを示していると思います。具体的なシナリオを持たないまま、何らかの代替手法で多目標処理についての要求性能を定量化した、と読み取れる記述もありません。「漠然とした「多目標処理」という要求にならざるを得ない」というのが、防衛庁の最終的な要求性能だったのではないでしょうか。

    そうであった場合は、審査においても、「漠然とした「多目標処理」」という基準が用いられることになるのではないでしょうか。

  25. 設計や試作の契約履行に際しては、一般の契約と同じく「契約書」があり、要求内容の「仕様書」があり、技術的詳細は「基本要求」として与えられるわけです。
    「基本要求」は技術的な要求なので、原則としては定量的な基準(要求値)が示されますが、定性的な要求が書かれていないわけではなく、例えば「2000年代初頭の〇〇環境に対応可能なこと」などという項目があったりします。

    定量的な要求値(たとえば搭載ミサイルや弾数とか、レーダーの探知距離とか)を満足できれば「2000年代初頭の〇〇環境に対応可能」だと言いきれればいいのですが、そういうわけでもありませんから、定性的なことも書いておくわけです。
    こうしておくと、設計の途上で「たしかに要求値は満足しているけど、本当にこんな実装でいいの?」というような問題が出てきたときに、それは「2000年代初頭の〇〇環境に対応できる」と言えないからだめ、という拒絶が可能になる。
    こうしたテクニックは、一般の仕事で契約書を作る場合も、よく用いられます。

    さて、ではどうやって「2000年代初頭の〇〇環境に対応できる」と判断するのかというと、会社側と防衛庁側が調整を重ねて、これならよい、と合意できた設計を「技術審査」に上程して、これを発注者である技本が承認するわけです。

    なので、「多目標処理」という漠然とした要求があったとしても、2機以上なら多目標でOKだよね、と低い次元で合意できるのなら問題ないのです。しかし「3機は可能だけど5機は無理」「それでは困る」というような問題が出てくると、会社側と防衛庁側が調整を重ねて合意点を探ることになります。
    ここで技本は会社と空自の間に入ることになりますが、技本の松宮さんとしては、こうした調整の中で空自の要求が具体的なシナリオに基づいていないことを痛感し、こういう反省の弁をしたためているわけです。

  26. そのご説明は理解がしやすいですけれども、だとすると、松宮氏の手記にある「このシナリオがないと、漠然とした「多目標処理」という要求にならざるを得ない」という記述は整合しないのではないでしょうか。正しくは、「シナリオがないまま、会社側と防衛庁側が調整を重ねて「多目標処理」を定量化したが、その要求性能は実環境とは乖離していた」と記述すべきだった、ということになりませんか。会社側と防衛庁側が調整を重ねて定量化したのに、そのことを「漠然とした要求にならざるを得ない」と記述するというのは、考えにくいと私は思います。

    そして、会社側と防衛庁側との調整によって定量化した場合は、会社側には何ら落ち度はないはずですよね。要求性能についての防衛庁側の主張が、具体的なシナリオの検討を経ているかどうか、あるいは実環境を反映しているかどうか、会社側は判断する術もありません。

    であるのに、松宮氏の手記では、反省すべき主体として防衛庁とともに会社も挙げられています。こう記述されています。「特にレーダーについては、運用を想定した実環境下での技術的要求事項を明確にして製造会社に要求する必要がありましたし、製造会社はそれを踏まえた設計、試験、評価をすべきであったということも大きい反省点の1つです。」

    会社側と防衛庁側との合意によって設計が行われたのであれば、この手記の記述は意味が通らないのではないでしょうか。正しくは、「運用を想定した実環境下での技術的要求事項を明確にして製造会社に要求する必要があったが、それを行わなかったため、製造会社はそれを踏まえた設計、試験、評価ができなかったということも大きい反省点の1つです。」と記述すべきだった、ということになります。

    松宮氏は、会社側も反省すべき点があるという立場を取っていますが、それは「技術的要求事項が明確にならないまま、会社が独自に判断して設計を行った」ということを意味しているのではないでしょうか。

    1. 松宮さんの書いている内容は「会社側も反省すべき点がある」という意味ではないと思います。
      「特にレーダーについては、運用を想定した実環境下での技術的要求事項を明確にして製造会社に要求する必要がありましたし、製造会社はそれを踏まえた設計、試験、評価をすべきであったということも大きい反省点の1つです。」
      というのは、私の理解では「正しくは」としてお書きになっているとおりの意味にしか受け取れませんでした。

      装備品開発の主体はあくまで技術研究本部であって、会社側が「独自に判断して設計する」ということは起こらないようになっています。
      設計時に会社が定めた技術仕様書の類を含め、設計のアウトプットは必ず技術審査を通過しますので、技本の意向と齟齬があれば審査に通過しません。技術審査というのは、まさに「会社で勝手に判断」させないための仕組みです。

  27. レーダーの設計、開発で用いられるシミュレーションソフトの製品説明がありました。
    https://jp.mathworks.com/discovery/radar-system-design.html
    「地上および航空機、船上、または自動車のレーダーシステムのダイナミクスを、移動するターゲットとレーダープラットフォームでモデル化します。」

    松宮氏の手記に出てくる「ソフトウェア」とは、設計で用いられるこの種のシミュレーションソフトを指すのではないでしょうか。
    「このシナリオがないとソフトウェアは組めずに、漠然とした「他目標処理」という要求にならざるを得ない。」

    推測するに、こういうことではないでしょうか。レーダーを設計し、パラメーターを設定するには、シミュレーションソフトによって検討することが必要だが、それには自機や目標の動きを規定する具体的シナリオが不可欠である。しかるに、防衛庁側は具体的シナリオを持っていないため、シミュレーションによって技術的要求事項を明確化する能力が無かった。

    とはいえ、シミュレーションソフトを用いなくては、設計を進めることはできない。止むを得ず、会社側は独自にシナリオを想定することを提案し、防衛庁側はそれを了承した。独自シナリオによるシミュレーション結果について防衛庁側は確認したうえで、設計案を了承した。

    1. このMATLABは汎用の数学的シミュレーションツールで、レーダーや電子機器だけでなく、さまざまな分野で使われています。

      >松宮氏の手記に出てくる「ソフトウェア」とは、設計で用いられるこの種のシミュレーションソフトを指すのではないでしょうか。

      設計で用いられるシミュレーションソフトではなく、運用のシミュレーションソフトウェアを指していると私は考えます。
      このMATLABによるシミュレーションで「ターゲットをモデル化」と書かれていますが、これは目標のRCSや移動速度などを数学的モデルにする、という意味ですから、そこのレベルでは「朝鮮戦争」も「ベトナム戦争」も「シナリオ」も関係なく、想定する目標の物理的諸元を設定すればよいだけです。
      一方、運用シミュレーションは具体的な作戦シナリオについて検討するものなので、敵味方の戦力に関わる想定データや、当該シナリオにおいて想定する敵味方の戦術など、軍事的な知見や方針が反映されることになります。
      松宮さんが指摘している問題は、こうしたシミュレーションの具体性を含め、開発に対する要求事項を決めるための検討に問題がある、ということなのです。
      (・ω・)

  28. 手記の指摘のように「運用を想定した実環境下での技術的要求事項を明確に」するためには、運用シミュレーションに具体的シナリオを入力して検討する必要がある、ということですよね。ですが、防衛庁は具体的シナリオを持っていなかったため、「漠然とした「多目標処理」という要求」になりました。

    もし、防衛庁が必要に迫られて急いでシナリオを用意した場合に、そのシナリオは実環境を反映する精度が低かったのだとしたら、手記では「実環境を正確に反映するシナリオを用意すべきだった」という指摘になるはずです。つまり、要求性能や技術的要求事項は明確化されたが、実環境を反映する精度が低かったのが問題だ、という指摘です。

    けれども手記では、「漠然とした要求になった」、「運用を想定した実環境下での技術的要求事項を明確にして製造会社に要求する必要がありました(技術的要求事項は明確化されなかった)」という記述になっています。

    これは、シナリオが必要になった状況においても、防衛庁はシナリオを用意しなかったことを意味するのではないでしょうか。しかし、レーダーの開発においては、運用シミュレーションにシナリオを入力して検討することが不可欠であると私は推測します。そして、不可欠であるシナリオを防衛庁が用意しなかったのだとしたら、会社側がシナリオを用意するよりほかに方法はないのではないでしょうか。
    (その場合は、会社側が用意したシナリオを、防衛庁がチェックしたでしょう)

  29. 「開発においては、運用シミュレーションにシナリオを入力して検討することが不可欠」とだとすれば、それは運用者が要求を固める時点においてであって、会社がレーダーのハードウェアや、それを駆動するソフトウェアを作る時点の話ではないのです。

  30. >会社がレーダーのハードウェアや、それを駆動するソフトウェアを作る時点の話ではないのです。

    この点でもお聞きしたいことがあるのですが、先にお聞きしたいことがあります。
    運用者が要求を固める時点において、防衛庁はシナリオを用意したのかどうか、どうお考えですか?

  31. >運用者が要求を固める時点において、防衛庁はシナリオを用意したのか
    間違いなく用意しています。
    というか、会社側に示される「基本要求」には、ミッション・プロファイルというのが付いていて、代表的な運用ケースについての任務シナリオがそこに示されているのです。
    会社では、様々な性能指標値を個々に満足させるのではなく、それらのシナリオを要求どおり実現できる設計をしなければいけません。

    しかし、そのミッション・プロファイルにおいても、戦闘様相の細部について書くには限界がありますし、下手に書いてしまうと逆に意味のない制約を加えることになります。なので、そうした細部について確認が必要なことは、開発の中で調整していくことになりますが、それは無駄なく良い製品を作るための合理的な方法です。

    書かなくてもいいことを書いてしまったとか、適当に設定した要求値が書いてあったとかの理由で、開発や調達の際に困ったケースも他機種では聞いていますので、あえて細かく書かない、というのも重要なノウハウだったりします。

    自衛隊では、日常的に様々なシミュレーションを細部まで行っており、それが彼らの仕事でもあるのですが、新機種開発の基準として明確に定められた細部シナリオは、用意できていなかったということではないでしょうか。

    1. ミッション・プロファイルというのは、たとえば対艦攻撃任務において、目標との距離100キロの地点から高度50メートルで時速800キロで飛行し、敵艦をどの距離でロックオンして…、というようなものでしょうか。
      空対空戦闘の任務においても、搭載武装、速度、高度、索敵距離、交戦距離といったものは想定されているだろうと想像します。けれども、敵の編隊がどのような構成を取っていて、どのような行動を取るか、そういった細部シナリオは用意していなかったのだろうと思います。その細部シナリオが、レーダーの開発では必要なのではないでしょうか。

  32. 戦闘機用レーダーの開発を、自動運転車の車載レーダーの開発にたとえてみます。車載レーダーにおいて、探知距離、走査範囲(角度)、走査間隔(時間)、最大追跡数、これらのパラメーターがトレードオフの関係を持つことになります(車載レーダーではどうなっているか、私は知識がありませんけれども)。

    自車や周囲の車が、実環境においてどのように判断しどのような行動を取るかを再現する。これが運用シミュレーションですね。そして、自車の周囲の状況を把握するためにはレーダーのパラメーターをどのように設定するのが最も適切か、設定を変更しながら運用シミュレーションを繰り返して、最適な設定を探ることになるでしょう。

    最適な設定は、運転の場面ごとに異なるはずです。戦闘機のレーダーでは、状況によってサブモードを切り替えます。仮に車載レーダーでもそうだとすると、高速道路用、駐車場用など、場面ごとにサブモードを用意して、運用シミュレーションを行って設定の最適化を行うでしょう。

    車載レーダーの開発初期に、要求性能や技術的要求事項を検討するに際して、実環境を反映した細部シナリオ(フィールドデータ)を用意して運用シミュレーションを行うことは、不可欠なのではないでしょうか。私の想像では、開発初期の段階では技術的要求事項の大枠を決めて、開発中にも様々な状況を想定して運用シミュレーションを行い、設定の最適化を行うだろうと思います。

    松宮氏は、「防衛庁はフィールドデータを持っていなかったため、ソフトウェアを組めず、漠然とした要求性能になり、技術的要求事項を明確化できなかった」と指摘しています。フィールドデータが無くては運用シミュレーションは行えませんが、その状態のままで開発ができるでしょうか。

  33. 「フィールドデータ」は「細部シナリオ」のことではありません。
    実際に取得された「データ」のことですね。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください