こんにちは、青島です。
OPUSAT-Ⅱの開発開始から4か月半ほど経過しました。
衛星のイメージも少しずつではありますができるようになってきたように思います。
僕たち2回生が衛星プロジェクトに配属された時は、ちょうどKITの開発が最終局面でしたので、OPUSAT-Ⅱまでは衛星開発のどのフェーズも体験していませんでした。
ですので、衛星について知識が不足していることが多く、勉強の毎日です。
OPUSAT-Ⅱの開発は、まずミッションを実現するための細かな機能(ここでは単機能と名付けます。)を実現することを目標に開発を行い、この単機能が完成したら統合を順番に行っていきミッション部を完成させる、という体制をとっています。
現在、単機能が実現され始め、最初の統合へ移ろうとしている段階です。
統合がしやすいようになるよう工夫はしているのですが、統合に備えてもう一度、どのような開発の仕方をしていくのかを考え直さなければならないかもしれないですね。
統合の時に隠れていたバグが出てくるといいますし。
また、単機能を開発するということは衛星の詳細な部分を見つめていることに近いと思います。
このような視点も大事だとは思いますが、このような場面だからこそ視野を広くして衛星全体を見ることもとても重要なのではないか、と考えています。
ですので、衛星全体のインターフェース、さらにミッション自体やそれから出てくる運用、要求、制約も視野に入れなければならないと思います。開発が進んできて、新たな情報なども出ていますので、考慮すべき点などが増えているかもしれません。
このようにやること、やることばっかり出てきて嬉しいような悲しいような感じではありますが、この状況を楽しんでいきたいと思います。
三歩歩いて二歩下がるような感じでいいので少しずつ少しずつ進んでいきたいです。
2017年初のブログになります．保田です
昨日「ローグ・ワン/スター・ウォーズ・ストーリー」という映画を見てきました．
映画自体大変面白かったのですが，この映画を見て，システムに故障箇所があっても
その影響を他に与えないようにすることはものづくりにおいてとても大切であると改めて感じました．
1か所の故障が他の部分も道連れにして，全システムの故障につながってしまったら大変ですからね．
以前に本センターの先輩方が開発し打ち上げられた衛星「OPUSAT」の場合，
1つの衛星で複数のミッションを行うため，少しでも成果を残せるよう，
ミッションAの機器が壊れてもミッションBはできるというような設計になっていました．
ある箇所での故障発生時に他の正常な箇所への悪影響を抑えるさまざまな工夫がされていたのです．
多少の故障で全損しないような強いシステムを作るためには，
目的の動作が実現できるように設計をするだけでなく，
もしここが壊れたら，この回路や他の回路はどうなるか
ということを考えながら設計することが必要になると思います．
しかし，システムを複数人で分担し，各々が分担されたところだけ見て設計をすると，
自分の担当範囲が正常に動作すればそれでよいと考えてしまいがちで，
自分の担当範囲で故障が起きたときに，自分以外の担当箇所にどんな影響が出るか，
どうすれば悪影響を与えないようにできるかというところまではなかなか考えが至りません．
システムを分担して開発する中で，故障による道連れが最小限となるように設計するには
分担して設計されたものを全部統合した後，分担に関わらずシステム全体を見て
故障による道連れが起こりうる箇所を探し，修正する作業が必要になると思います．
現在設計が進められているOPUSAT-IIも分担して開発を行っているので，
統合する段階での故障による道連れ防止設計を意識していきたいと思います．