2,000 万行
先月の「NETWORK WORLD」によると、ジュニパー・ネットワークスのルータで使用している OS「JUNOS」の最新版は、ソースコードが全部で 2,000 万行ぐらいあるとのこと。
一方、F-35 Lightning II で使用するソフトウェアは、ソースコードが全部で 2,200 万行ぐらいあるという話。
エンタープライズ向けの、巨大で高性能なルータを駆動するためのソースコードが「2,000 万行もある」というべきなのか。それとも、第 5 世代戦闘機を飛ばして戦わせるためのソースコードが「2,200 万行で済んでいる」というべきなのか。これだって、F-22A と比べたら 3 倍ぐらいあるんですが。
ソースコードの行数だけで、規模や開発の手間などを判断するのはナンセンスな話ですけれど、個人的には「JUNOS がけっこう巨大なんだなあ」という印象でした。もっとも、JUNOS をテストするのに飛行試験用の CATbird は必要ありませんけれど :-)
« 行政訴訟のフルコース | Main | 銀塩一眼 »
Comments
この辺微妙なところで、信号処理の組み込み系の全てとは言いませんが、中身をみると結構いい加減な(悪意をもった見方)というか、こういう近似解法があるのか(好意的な見方)といった、信号処理の解説本には書かれてはいないけど実用的かつ簡潔なソースであることが多いです。特に軍用は。だからソースコードの行数と機能量が直線的じゃないことが結構多い。いや、正確には多かったか。組み込み系の人は達人級の人にしか任しちゃなんないみたいな状況がその昔あったという感じか。今も若干ありますけど。
最近はというと機能分散化が進み要所要所にPLD、PGA、DSP及びミクスドシグナルDSP等が入り込んでたりするので、これまたメインを走らせるMPU用ソースコードの量だけでは機能が把握できなかったりなんか。信号フロントエンドがあって、情報のSNを高くした後にMPUに受け渡すみたいな設計が最近非常に多いですね。COTSの影響もあってか、機能部分を外出しにすることで、とかくディスコンになりやすい民生部品使用部分の再設計費を出来る限り減らそうという努力の表れでもありますが。これが最新のシステムの傾向と言えるかな。
そうじゃない、妖しげというか、南アメリカ某国等にまで良く輸出していたヨーロッパ系某社製ともなると、誘導弾の制御は温度コントローラ並の手軽さで作られていたりする(PID＋警報値制御)わけで、これでも動くんだ…という感じで極東某国製汎用ロジックICとか汎用タイマICがびっちり詰まったボードが刺さっていたりしています。PLDにしとけばもっと楽なのになあ、とかIFをPAR−SER/SER-PAR変換させればいいだけなんだから、もっとコストダウンできるのに…とか思ったものです。まぁ、だからこそメンテナンスに法外とも言える費用を請求できるんでしょうけど。
Posted by: あっさむ。 | Jun 30, 2008 11:49 PM
>機能部分を外出しにする
スパイラル開発で段階的に能力を向上させていくときにも、全部がひとかたまりのモノリシックになってたら不便でしょうから、必然的にこういう方向にならざるを得ないんでしょうね。サブシステムはサブシステムで自分の仕事をして、それをネットワーク化した上で中核システムがコーディネートしながら System of Systems を構成する、みたいな。
>極東某国製汎用ロジックIC
ちゃんと動けば勝ち、ともいいますけれど、それでええんかい ! と突っ込んでみたくもなりました。
Posted by: 井上 | Jun 30, 2008 11:56 PM
そういえば、デイル・ブラウンの小説「スカイ・マスターズ」で、B-2A にスーパー・コックピットを取り付けようというところで
「ソフトウェアの書き換えは、ほんの数ヶ月で済みます」
という台詞がありまして。それを見て「そんな簡単に済むかヴォケェェェェ」と、本に向かって突っ込みを入れてしまいました。
Posted by: 井上 | Jul 01, 2008 12:06 AM
まー、なんつーか。
結局、いまどきのソフトって、行数が問題ではなかったりするんですよね。
以下に後日変更時に、手直しとかリファクタリングせずに済む様にするとかが重要であって。
少ない行数で作っても、他人が見て分からんソフトは、１００％動くもの以外はゴミです。
それにソースコードの行数って事は、コメントの行数も含んでるでしょうし、そう考えると基本英語で統一されてるんだろうけど、複数の国人向けに付けられた英文って、契約にがんじがらめでアホ見たいに長いし。
実動行数って、何行になることやら。
まぁ、幾ら欧米大企業と言っても、ＪＡＰにゃ難しいロジックはわかんねーだろ？ってスラングで電話してくるアホもいるし、
そんで送りつけてきた資料がフローチャートが
間違ってて添削して送り返してやったら、
さらに汚いスラングで電話してきたり。
１０年前でも、かるふぉるにあの北部から悪口言うためだけに、国際電話一時間てお金持ちの企業は違うねぇ（ぉ
は！話が後半かわっちゃった（ぉ
Posted by: あるくびゅーず | Jul 01, 2008 10:45 AM
ウェポン システムに限ったことじゃないですけど、コード管理や品質の問題だけじゃなくて、アルゴリズムの良し悪しって問題もありますしねえ。
どんなにキレイに無駄なく書かれたソースコードでも、アルゴリズムがタコだと戦の役には立たないでしょうし。
イージスみたいにバージョンアップを重ねてきているシステムだと、その辺の熟成が相当に高い水準で進められてきているのではないかな、なんてことを考えています。
Posted by: 井上 | Jul 01, 2008 03:47 PM
>井上氏
ホント何でもありっな世界でもあるんですよ。趣味の電子工作においては定番的なPICを筆頭とした各種マイコン、ロジック、どっかのモーター用アンプとか使いまくり。性能としては推して知るべしというレベルではありますが、忘れてはならないのはそういったものほど基本に忠実な作りなわけです。制御理論に忠実。逆に言えば「分かっているからこそ」提示された取得コスト、輸出国の事情に合わせて機能を削ぎ取れるのだとも言えます。でも、いくら取得コストが安かったからとはいえ基盤交換が必要になった場合、一枚数百万とか請求するのはとっても酷いと思います(棒読み)。
でもって、巨大なハードウェア。面倒なのは何らかの(ネットワークなり、各種バスなりの)シェアードメモリ方式を用いたブロック転送による情報共有。こいつですね。常に同期できれば良いんですが、通信状態によっては同期性が保たれない、その場合はどうするのか。送信バッファをどんだけ積めばいいのか、もっとデータを圧縮できないか、同時にメモリアクセスが発生した場合は？、、、と、熟成を重ねることで得られるものは「抜けるところは徹底的に手を抜く」「ほどほどにしとく」という部分ですね。主に。この曖昧な部分を定量化するにはやっぱりある程度の運用結果に基づかないと抜いてはならない部分を手抜きしちゃう訳で。ま、手抜きした事で得られるのはスキャンタイムの高速性、制御の確実性とか更なるファンクションの追加もしくは既存ファンクションの高精度化につぎ込まれちゃう訳ですが：）
Posted by: あっさむ。 | Jul 05, 2008 11:30 AM
そういうのって、まさに「自分で作って苦労してみないと分からない」って世界ですよね。デッドコピーしただけでは、どうしてそういう設計になっているのかが分からないし。
>同期
そういうところも、システム インテグレーション屋さんのノウハウが活きるところなんでしょうね。ただ単に線をつないで済むなら、インテグレーターなんて要らないわけですから (暴言)
Posted by: 井上 | Jul 05, 2008 12:52 PM
あっそうそう。
上には上があるもので、米陸軍の FCS は、全部ひっくるめて 6,000 万行ぐらいのソースを書くようです。
Posted by: 井上 | Jul 05, 2008 02:14 PM