人工衛星本体と試験装置を分ける
試験で異常なデータが出た時に、設計者であるならば、ある程度予測はつくでしょう。
回路のどの部分が故障すれが、このデータが発生するのか。
そもそも回路が原因ではなく、ケーブルが原因で発生してしまった事象など、想像がつかない場合は、基板を取り出し事象を確認していくことでしょう。
人工衛星の場合は、高温の他に低温でも試験を行います。
自動車の試験の場合は、高温での試験が行われますが、低温の試験はどうでしょうか。
ただ、低温といっても、0℃とか氷点下に下がるだけだったりします。
極低温といっても、マイナス100℃を超えるレベルではないのでそれほど驚くものではありません。
まあ、この感覚は研究レベルで極低温というと0K近傍の試験をしていた自分の間隔なので、その辺は人それぞれかもしれません。
電子機器というのは温度を掛けた時にのみ不具合が発生することが良くあります。
電子部品は基本、常温といわれる20℃～25℃の温度にて平常な動作をする部品が多いのです。
自動車に使われる部品であれば、100℃近くまで使える部品も存在はしていますが、やはり調整していないと高温では安定しません。
部品単体では問題なくても、銅線への影響や、ベタといわれるはんだの膜であったり、ホールの箇所などいろいろあります。さらには熱による熱雑音が発生することで、主なぬ電子部品が影響することもあります。
熱は厄介です。
各種測定器は基本常温で使われます。
基板回路上で、どの電子部品が悪いのか確認するには計測機器の端子をあててみる必要があります。
もちろん、シミュレーション上で確認する手法もあるので、計測機器の端子をあてるというのは、手法としては古くなっているかもしれません。
ただ、熱雑音の場合ですと、基板を取り付ける筐体からの漏れもあるため、そこまでシミュレーションで模擬しているでしょうか。
不特定な値が多すぎるため、シミュレーションで確認するより基板で直接確認した方が早いのです。
さて、計測機器の端子をあてる場合は、筐体から外に出さなくてはいけません。
人工衛星の熱試験は、恒温槽であったり真空試験装置(チャンバー)に放りこんで温度を変化させるのですが、よほど大きなチャンバーがなければ常温で測定します。
大きなチャンバーがあって、高温で基板を出せたとしても、今度は計測機器が異常な値を出すとも限りません。やはり、常温で測定します。
もちろん常温で測定しても不具合が発見できないこともあります。
しかし、それでも事象を確認し、関連性のある特性を探していかなければいけません。
こういったことがあるために、人工衛星の各機器の基板をフレキシブル基板にして薄くするのは難しいのです。
不具合分析ができなくなるのが主な理由ではあると思いますが。
ただ、今後の軽量化や耐衝撃性を考慮すると、すでに実施している機器もあるかもしれませんが、特殊な部品を実装しない基板はフレキシブル基板に移行していくでしょう。
構造的には、そっちの方がとても楽なんですけどね。
まあ、そこまでそんなこんなで不具合を追求しなくとも、ある程度の部品や箇所の特定ができれば、予備品を使ってリトライするというのも一つの案です。
人工衛星を製造しているのであって、研究者ではないのです。
工学的知見や、企業的なコストやリスクを考慮して、途中で切り替えるというのも十分必要です。
もちろん、不具合として情報を後世に残す必要はあります。
スケジュール観点や手間だから、今は必要ないといって残し、後世に残しておかないと、同じ失敗を起こします。
人工衛星、というかシステム設計としては必要な行動なんですね。
とまあ、開発者の場合は、不具合が発生した時に、不具合が発生した対象に注意を向けがちです。
ただし、人工衛星用治具なども不具合を起こすということも忘れてはいけません。
不具合追及の際に、最初につぶしておく必要があるのは、治具あるいは試験装置での不具合です。
FTAの解析においても、最初に人工衛星本体と治具の二つの可能性を挙げておき、つぶしておいた方がいいです。
今まで発生した大半の原因が人工衛星本体だとしても、治具による不具合もゼロではないのです。
思はぬタイミングで不具合が発生した時、本体をいくら探しても不具合の原因が分からず、最終的にいくつかの検証プロセスを戻って、治具あるいは試験装置の健全性を確認する羽目になるのです。
試験装置の健全性の確認というと、校正期限や定期点検、特注治具であれば、動作確認や入力プログラムの確認、過去の試験と同じプログラムを使用しているのか、変更している箇所がないか、変更されていれば何が違うのか、桁が間違っていないか、入力箇所を間違えていないかなどです。
試験装置の確認は、人工衛星の開発者でなくてもできます。
不具合が起き、人工衛星の中身をさらって、検証する際、多くは設計者が確認することになるかと思います。
つまり設計者の時間がとられてしまうのです。
では、非設計者である技術者たちはどうでしょうか。開発者なり設計者が取得するデータが得られるまで、待ちになります。
そこで、開発者とは並行して試験装置の不具合の可能性をつぶすことはできないでしょうか。
少なくとも、今までそこまで実施できているチームは見られませんでした。
指示されたことのみに注力する。
指示は本体の調査しか言われていないので、本体の調査しか進みません。
指示する側も、本体しか目に行っていないか、まさか、過去にあれほど失敗していたという記憶がある試験治具の不具合を見過ごしてしまうのです。
あるいは、継続シリーズの人工衛星の場合だと、過去の実績で問題なかったから、試験治具が問題発生するとは思わないのかもしれないですし、単なる視点が抜けているのかもしれません。
治具や試験装置の不具合は一定数存在していていることも事実です。
プロジェクトの最初のうちに、治具の不具合が発生していれば、そのプロジェクトでは最初に試験治具の不具合を疑います。
ただ、人間は忘れるものなので、別のプロジェクトになったり、担当が変わればその視点も抜けてしまいます。
たまたま試験治具の不具合が発生しないプロジェクトの場合はどうでしょうか。
きっと知見が失われることでしょう。
システムや仕組みに落とし込むことが大事
不具合の発見の知見は、その組織のノウハウといってもいいでしょう。
場合によっては、発生した不具合の恒久処置で特許を取得することができるかもしれません。
不具合は宝などと、似た言葉を言う人もいるでしょう。
それら得た知識を、十分にシステムの中に落とし込むことだけでは足りないのです。
人工衛星は、複雑なシステムです。
サブシステムで担当が違うことはよくあります。
案外サブシステムごとでの文化が作られ、他のサブシステムでは共有されないということもよくよく見られます。
組織として事象が共有できる仕組みやシステムづくりも人工衛星を継続的に作っていくには必要なのです。
個別のグループや担当内だけで共有するのではなく、同じ組織(企業など)では、情報は共有しておくに越したことはありません。
でないと、品質保証や品質管理部門の方々が、同じ人工衛星内なのに情報が共有されていないと指摘してきます。
ただ、各設計者・開発者は、時間の余裕がなかったりして、常に隣のグループの不具合をチェックすることはできません。
情報共有ツールを使用したり、品質保証側の人間が、展開しておく必要もあるかもしれません。
