開発終盤、納期間近にも関わらず実機のトラブルで、ハード屋やソフト屋が計測器を抱えて走り回ることを、技術者であれば何度か経験があるのではないでしょうか。

ハード、ソフト、どっちが悪いのでしょうか！？

こういった経験を異分野の技術者同士で討論し、明日から使える問題解決のヒントを探るため、Design Solution Forum2017では、参加者主導型の「ハード屋＆ソフト屋　ディスカッション」特別企画を実施します。

昨年のDesign Solution Forum2016では「ハードウェア・エンジニア vs ソフトウェア・エンジニア討論会」が実施されました。ハード屋・ソフト屋、計６名のパネラーが不具合事例を題材に、思い思いのことを議論しました。討論後、当日の参加者からは、“私の現場でも同じことが起き、困っています！！“　といった共感の声を頂けました。パネラーも、何かしら継続していきたいという想いから、Design Solution Forum2017では、参加者も議論できるような特別企画を考案しました。そこで今回の特別企画に合わせ、昨年の討論会の様子を記事にしております。

■情報伝達の想定外をなくすためには？

-事例１:ワークアラウンドで割込みをケアできず・・・

事例１は、実行時間や応答時間などのオーダーについて、ハード屋とソフト屋との認識違いで起きた事例になります。ハード屋は、ある一定の遅延対策を導入した際、問題が回避できる手段を局所的に考えがちで、ソフトがどのような制御を行っているか全体が見えていないことがよくあります。ソフト屋は示されたフローチャートに従って、複数の機能を同時に実現するため、割り込みベースで全体を制御することを考えます。そのため、時間制約に関する記載が重要ですが、ハード屋が当たり前に使っているタイミングチャートは、ソフト屋からすると、理解しづらいチャートです。討論の場では、仕様書の制約の書き方だけではなく、ハード屋がソフト屋へ回避策を提示する前段階での対応や、想定外の制御を無くすためにフォーマル検証が使えないか、の議論が行われました。

■大量の仕様情報から設定ミスを回避できるのか？

-事例２:制御変更によりレジスタ制約にひっかかる

事例２は、開発の最終工程に発生した性能未達問題の回避策として、制御手順を変更した際にレジスタ設定の制約を違反してしまった、事例になります。ソフト屋は、効率よくレジスタ設定を行うためにパラメータを共有化し、制御に応じて処理させ、その変数を読み書きします。ハード仕様としては、単一モジュールの制約事項をソフト屋は把握していますが、モジュールを複合的に扱う場合に、その制約事項がどう依存しあっているか把握しきれていません。討論の場では、こちらも事例１と同様に仕様書の書き方の話だけでなく、そもそも最終工程で性能未達になってしまった要因、ハード検証環境を活用したソフトの早期開発やデバッグ回路の挿入に関して、議論されました。

今年のDesignSolutionForum2017の「ハード屋＆ソフト屋　ディスカッション」特別企画では、ライトニングトーク＆実機検証アイディアソンを行います。この記事をご覧になられて、私もこう言いたい！！と、ご意見を頂ける方を、ライトニングトークの発表者として募集しております。そこで思う存分あるべき論を展開してください。対象者をハード屋・ソフト屋の枠に縛らずに募集していますので、当日の議論の場では、異分野の新しい知見を得られますし、さらには新たなアイディアが生まれるかもしれません。ハード屋とソフト屋の垣根を越えて、明日から使える問題解決のヒントを探りましょう！！

「ハード屋＆ソフト屋 ディスカッション」ライトニングトークの発表者事前登録はこちら

文：Design Solution Forum 2017 実行委員　守田　直也