往時宇宙飛翔物体 システム機械設計屋の彼是

往時宇宙飛翔物体 システム機械設計屋の彼是 宇宙blog

人工衛星の設計・製造・管理をしていた宇宙のシステム・機械設計者が人工衛星の機械システムや宇宙ブログ的なこと、そして、横道に反れたことを覚え書き程度に残していく設計技術者や管理者、営業向けブログ

代替の経済性(economies of substitution):再設計するコストは新規のシステムを構築するコストを上回る【基礎から知りたい】

f:id:MSDSSph:20220214232814j:plain

代替の経済性(economies of substitution)

代替の経済性(economies of substitution)とは、最初から再利用や交換を考えて設計した製品の開発コストは、製品を再設計するよりコストが低いことを示す概念です。

 

生産までに時間がかかる製品

人工衛星は、いま世の中に広まっている製品に比べて、一部の例外であるスペースXのスターリンク衛星やOneWebの人工衛星を除いて、それほど製造されてもいません。

人工衛星としていますが、一般に生産までの時間が短縮できない製品やユーザー数が圧倒的に少ない製品と読み替えても問題ありません。

 

圧倒的に製造数が足りないにもかかわらず、長期間の運用になります。

その際にいくつかの心配事項はありますが、その一つに部品の製造停止があります。

 

電子部品や電子機器は、通常ずっと提供されるものと思われるかもしれませんが(笑)突然製造停止になります。

 

正確には突然ではなく、2,3年前に連絡があるのですが、宇宙機開発は長期スパンであることから、開発側からすると突然製造停止と感じるわけです。

 

実際大手企業であれば連絡があるかもしれませんが、ベンチャー企業、中小企業ではその連絡が突然と感じることもあるでしょう。

 

製品の製造停止

製品が製造停止となる理由はいろいろです。

 

もっと儲かる製造ラインを拡張するために従来の製造ラインが縮小されたり、工場が倒産したり、本当にいろいろです。

 

さらに部品だけではなく、電子機器も突然製造停止になります。

 

理由の一つとしては、製造していた技術者や設計者が会社から退職してしまい、十分に引き継がれることなく技術が消失してしまうこともあります。

 

あるいは十分な利益を見込めないことから会社判断で受注しないこともあります。

 

人工衛星の製造サイクルは、通常の製品よりも長く、同型品を製造するにも選定した部品や機器がマイナーチェンジをしている可能性があります。

 

宇宙業界の世界ではまだまだ過去に宇宙で使用されたという「実績」が大きなウェイトを占めています。

 

そのため、このマイナーチェンジをどの範囲まで許せるのかは各プロジェクトの方針によるところが大きいです。

 

過去と比較しても、許容する範囲は広がっていますが、一部の放射線に弱い電子部品はどこもほかの電子部品と比べて厳しい基準であることが多いです。

 

その中でもマイナーチェンジを受け入れて、振動試験を実施した結果、構造が弱くなり破損したり故障が発生することも少なくありません。

 

この微妙な違いによって発生した原因追及を含む不具合対応や、不具合が起きなくとも1台目より厳しい再確認を実施することもあります。

困ったことに1台目の設計開発者が現場から離れたことにより、よりトラブルが深みにはまることもあります。

 

そして、次号機以降も設計し直す(再設計する)ことになり、コストが積み重なっていきます。

案外、2号機目のシステム開発の方が苦労することが多いのではないでしょうか。

 

結果、タイトルの代替の経済性(economies of substitution)に繋がるのです。

 

トータルコストを減らす

人工衛星は、1台目は実証という側面が強いのですが、2台機目以降は「電子部品や電子機器が以降交換する可能性があるもの」として設計を進めた方が、トータルコストが安くなっていきます。

 

既存部品の再利用を前提とした製品システム開発コストが、システム全体を再設計するコストより低いことを示す概念です。

 

では実際何をしたらいいのか?

 

試作機をどこまで仕上げるかによりますが、すでに世界中で並走している宇宙機の電子機器(コンポーネント)の特徴を調べ、ある程度適合していくように設計していることです。

現在は小型衛星市場が活発であることから、電子機器の小型化が進んでいます。

それに伴い、その小型化に適合できるような拡張性のあるインターフェースを設計していくことになります。

参考情報として、この考え方はスケーラビリティ(scalability)といってシステムの拡張性を指すときに使用されたりしますが、今のところ宇宙業界ではあまり使われていません。

 

構造面からいうと、インターフェースといえば、設置する固定穴だけではなく、排熱や蓄熱の設計、信号や電力の流れるケーブルの配線位置、電磁波の影響を考慮した配置、振動の影響を考慮した設置部などを考えた上で、現在採用している機器以外も適用される可能性を考慮して設計していかなければなりません。

ちなみに、発熱だけではなく蓄熱を考慮する必要がある理由は、中・大型衛星ではそれなりに巨大な構造物となるため熱が逃げにくいため排熱を考える必要があり、超小型・小型衛星では熱を留まらせるほどの構造物ではないため蓄熱を考える必要があります。

 

これは電子機器側だけを標準化などといって設計の制限をするのではなく、電子機器の設計が変わったとしても対応できるようなメインとなるシステム側も拡張性を考慮した設計にしなければ、後続のベンチャー企業や途中参入してきた大企業にあっという間に技術面で追いつけなくなってしまう可能性を留意しなければいけなくなることでしょうね。

 

これは、1台目の設計にかかる設計者への負荷が大きいかもしれませんが、プロジェクト全体のトータルコストや後続の参入者に対して優位性を示すことができるのではないでしょうか。

 

もちろん、限られた資金や計画の中で成立させるのは非常に難しいのですけどね。

 

システムエンジニアのジレンマ:コストとリスクとパフォーマンス

最後にNASAで公開されている「Systems Engineering Handbook」からシステムエンジニアのジレンマを紹介します。

 

At each cost-effective solution:
• To reduce cost at constant risk, performance must be reduced.
• To reduce risk at constant cost, performance must be reduced.
• To reduce cost at constant performance, higher risks must be accepted.
• To reduce risk at constant performance, higher costs must be accepted.
In this context, time in the schedule is often a critical resource, so that schedule behaves like a kind of cost.

https://www.nasa.gov/seh/2-5-cost-effectiveness-considerations

それぞれの費用対効果の高いソリューションで:

  • 一定のリスクでコストを削減するには、パフォーマンスを低下させる必要があります。
  • 一定のコストでリスクを軽減するには、パフォーマンスを低下させる必要があります。
  • 一定のパフォーマンスでコストを削減するには、より高いリスクを受け入れる必要があります。
  • 一定のパフォーマンスでリスクを軽減するには、より高いコストを受け入れる必要があります。

スケジュールの時間は、重要なリソースとなるため、一種のコストのように考えることもできます。

 

限られた資金でプロジェクトを成立させることは難しいのですが、何をつかみ、何を切り捨てるか、もっとも端的でわかりやすい考え方だと思ったので載せておきます。

 

参考文献

コア部品サプライヤーを中心する企業間分業における知識獲得と意思決定権限―スマートフォンの開発事例―

https://www.jstage.jst.go.jp/article/amr/16/4/16_0161205a/_pdf/-char/ja

NASAが打ち上げのアウトソーシングに依存していることは、宇宙機関にジレンマを引き起こします

https://theconversation.com/nasas-reliance-on-outsourcing-launches-causes-a-dilemma-for-the-space-agency-44013

Biden’s China space dilemma

https://www.politico.com/newsletters/politico-space/2020/12/18/bidens-china-space-dilemma-491186

Bringing Space Law Into the 21st Century

https://www.realcleardefense.com/articles/2020/12/15/bringing_space_law_into_the_21st_century_653203.html

データベース・パフォーマンス・チューニング・ガイド

https://docs.oracle.com/cd/E82638_01/tgdba/designing-and-developing-for-performance.html#GUID-F8511B21-9EEA-4F1D-A1A0-C7CCEF914503