Tech Blog
怖くないEOL対応！手戻りを防ぐ『N-Process™』
小野です！
よろしくお願いします！！
よろしくお願いします！！
こんにちは、小野です。
今回は、久しぶりの報告であり、緊急でブログを執筆しております。
小野君、突然ですが、面白い話があります。
はい、ボス。今日は何でしょうか？
これはまあ、私の知り合いの苦労話なのですがね。
知り合いがEOL対応を手掛けていたんです。新しいCPUの仕様に合わせて設計変更し、これで大丈夫と思って置き換えCPUにプログラムを組み込んで、評価を始めた。
知り合いがEOL対応を手掛けていたんです。新しいCPUの仕様に合わせて設計変更し、これで大丈夫と思って置き換えCPUにプログラムを組み込んで、評価を始めた。
EOLって、つまり部品やデバイスが製造終了する（End of Life）ということですよね。確かに当社も、それについてたくさんご相談をいただいています。
新たなCPU用にプログラムを組み込むまでは順調だった。だが、評価の最中に――「あれ？なんか…違うぞ…。」そう、言葉にならない“違和感”が首筋を撫でるようにやってきた。一人静かに異常を探る時間が続いた。
あれ、面白い話だと思っていたら…なんか違うぞ…。
もう深夜の時間、周囲は静まり返り、ただ部屋の蛍光灯がわずかにノイズ音を発している。そんな時だ、奇妙な感覚が足元から沸き上がった。
「おかしいぞ…本当におかしい…。」
設計レベルのズレなのか、プログラムのバグなのか…謎の問題が発生。
ただただ、時間が過ぎ、ようやく完了した時にはスケジュールの大幅遅延…。
その後、彼の姿を見た者は誰もいなかった――。
設計レベルのズレなのか、プログラムのバグなのか…謎の問題が発生。
ただただ、時間が過ぎ、ようやく完了した時にはスケジュールの大幅遅延…。
その後、彼の姿を見た者は誰もいなかった――。
ちょっと！
これは怪談に見せかけたブラックな話じゃないですか！まさか当社で実際に？
まさか、そんなことはありません。フィクションです。
ほっ…。でも、この話から分かる通り、製造終了した部品への対応って本当に慎重にならないといけないんですよね。特にコロナ禍ではサプライチェーンの混乱や半導体需要の急増で部品が手に入らず、置き換え開発に関するご相談をたくさんいただきました。
CPU置き換え開発は本当に慎重にならないといけないんだってことが分かったと思います。そこで、当社はCPU置き換え開発を効率的に進めるための新たなサービス、その名も「N-Process™」を立ち上げました！！
おおおぉ！
「V字プロセス」はよく聞きますが…「N」ってなんでしょう？ぜひ紹介をお願いします！
「V字プロセス」はよく聞きますが…「N」ってなんでしょう？ぜひ紹介をお願いします！
置き換え開発の問題
小野君。EOL対応において最も重要なことって何だと思いますか？
置き換え作業で部品が変わっても、機能がうまく動くこと…ですよね？
その通り！「置き換える前と後で機能が全く同じであること」これが絶対条件なのです。
でもね。先程話したEOL対応の怪談、いやエピソードの問題点はどこにあったのでしょうか？
でもね。先程話したEOL対応の怪談、いやエピソードの問題点はどこにあったのでしょうか？
言葉にならない「違和感」が問題…ですか？
それとも部品の相性でしょうか？
それとも部品の相性でしょうか？
実はもっと根本的な問題があって、それは「事前検討が不十分だったこと」なのです。
事前検討が不十分？でも、お客様が社内で作ったものなら、社内の知見は十分あると思います。事前検討が足りないなんてことがあるのでしょうか？
そう思いたいところですが、現実はなかなか厳しいんです。たとえば、10年も20年も前に作った製品だとどうなると思いますか？
そう言われると、確かにその頃の設計者って退職されていたりしますよね。もしかして設計資料もないとか？
その通り。そうなると、新しいデバイスに置き換えしようにも、現状を理解しようにも情報が足りず、手探り状態で置き換え開発を進めざるを得ないことがあります。結果的に本開発後に改良設計が発生して、開発期間が大幅に延びてしまうなんてことになってしまうんです。
なるほど…。曖昧な状態で進めると、その「曖昧さ」が後々の落とし穴になるんですね。でも、事前検討が重要と言われても、具体的に何をすれば良いのかわからないです…。
それでは次の章で徹底解説します。寝ないでついてきてくださいね（笑）
プロセス ～VからNへ～
さて、事前検討の重要性について話してきましたけど、それを具体的にどう進めていくのか、以下にポイントをまとめました。
- 現行機のソフトウェアの素性・特性・評価基準の把握
- 潜在課題の把握
- 設計ドキュメントの品揃え
- 機能の等価が証明できる評価環境
確かに重要そうですが…。現行機の仕様や課題を全て網羅するとなると、設計ドキュメントだけで十分でしょうか？仕様の理解を深めるには他にも何かある気がします。
グッドクエスチョン。設計ドキュメントだけでは足りません。現行機に含まれている仕様や課題をしっかりと見極めることが重要です。そこで行うのが、「リバースエンジニアリング」という手法です。私たちはこのリバースエンジニアリング「iRES™」として実施しています。
なるほどなるほど！リバースエンジニアリングをして現行機を“分解”しながら調べるわけですね。この事前検討によって、改良開発の期間がなくなって本開発の期間で完了する仕組みが「N-Process」というわけですね。ホントだ、プロセスが「N字」になってます！
ボス。そのリバースエンジニアリングの「iRES」ですが、具体的にはどんな情報を掴むんですか？
たとえば次のような現行機に関する情報を把握するのが重要です。
STEP1：リバースエンジニアリングで“現行機のすべて”を掴む。
＜現行機＞・・・ソフトウェアの中身、特性、評価基準を把握する
- 現行機のROM・RAM使用量
- CPU負荷状況
- ソフトウェア処理性能 余裕度
- 現行機ソフトの設計資料は存在するか？情報は正しいか？
- ソースコードにCPUやOS依存コードはないか？
- ソフトウェア構造上の性能ボトルネックはないか？
いっぱいあるんですね。でも後で落とし穴にはまらないように必要な情報です。最初から必要な情報をきちんと集めるわけですね。
その通り！この情報が無い状態だと、リバースエンジニアリングが無意味になってしまう。何を調べるべきなのか、どの情報が重要なのかを最初に特定することが、このプロセス成功の鍵といえます。
その次のステップでは何をするんでしょうか？
STEP2では、リバースエンジニアリングで集めた情報を基に最適な代替デバイスとなる新しいCPUを選定します。
そして、事前検討のSTEP3では、本開発で、現行機と開発機の機能の等価性検証を行うための評価環境を構築します。
STEP1のリバースエンジニアリングが、この後のCPU選定や評価環境構築に大きく役立つんですね。
YES！評価環境を構築する際は、当社ではシミュレーション環境を活用して現行機と置き換え後の開発機の機能が等価であることを検証するための環境を構築します。
「N-Process」の肝と言える部分ですね！
「N-Process」の肝と言える部分ですね！
検証って、具体的には何を検証するんです？
このシミュレーション環境では、実機コード、コンパイラ、デバイス依存コードに加えOSやミドルウェアも含めて検証します。
シミュレーション環境では、ハードウェアに依存する部分の等価性も確認できるんですか？
確かにハードウェアに依存する部分は、等価性が難しいところはあります。
しかし、実機コード、コンパイラ、デバイスに依存したコードでシミュレーションできる環境を準備します。OSやミドルウェアも含めた形で、検証できるような仕組みを構築することで、より実機に近い形でのシミュレーション、等価証明が可能と考えています。
しかし、実機コード、コンパイラ、デバイスに依存したコードでシミュレーションできる環境を準備します。OSやミドルウェアも含めた形で、検証できるような仕組みを構築することで、より実機に近い形でのシミュレーション、等価証明が可能と考えています。
基本は「正確な評価データを準備する」ことが重要です。評価データというのは、現行機と開発機共通で使用可能なテストパターンと正解データです。
これが、シミュレーションの信頼性を支えていると考えています。
これが、シミュレーションの信頼性を支えていると考えています。
実機コードでシミュレーションできる環境を構築すれば、精度の高い検証ができるわけですね。シミュレーションには、現行機と開発機で使用する評価データの準備も重要ですね。
本開発
いよいよ本開発に入れますね。事前検討で得た成果物が十分揃ったおかげで、スムーズに進められそうです。
ですね、でも本開発に入る前に、お客様と成果物を共有することがとても大事です。成果物を基に、開発要件をお客様と一緒に確認して、「置き換え開発の要件をどこまで適用するか」をはっきりさせてから取り掛かるのが基本です。
確かに。成果物を共有しないと開発中に認識のズレが発生して手戻りになる可能性がありますね。
本開発では、事前検討での成果物を再利用することができるんですよね？だからこそ、全体の開発期間が短縮するってことですね。
はい、本開発では、事前検討で積み上げた基礎情報がそのまま使える。これが「N-Process」の大きな強みなのです！
ちなみに成果物ってどんなものがありますか？
事前検討で出てくる成果物は、たとえば、次のようなものがあります。
- 機能仕様に関する要件定義書
- ソフトの基本方式に関する設計書
- リバースエンジニアリングで判明した課題と改善項目のリスト
成果物を基にすれば、一から開発を始める必要はありません。課題や要件が明確だから、効率的な進行が可能になります。たとえば、リバースエンジニアリングで特定した「性能ボトルネック」の改善も、本開発の段階では具体的な実装に落とし込めますからね。
だから「N-Process」では、手戻りが発生しにくく、スムーズに進められるわけですね。
開発の手戻りを防ぎ、置き換え開発完了までの期間を短縮することが、このプロセスの最大の特徴です。
いやあ、「N-Process」が効果的だっていうのがよくわかりました！でも本開発が終わったら、その後に重要なことってありますか？
もちろんあります。本開発で「N-Process」は完結ですが、その後には、置き換え後の製品がきちんと動作するかどうかの「最終検証」が待っています。その話は今度じっくり話しますかね！
最後に
「N-Process」の最大の目的は、「手戻り作業を最小限に抑えること」です。当初の設計とは異なる機能が開発されたり、CPUを置き換えした後に期待した性能が発揮されなかったりする不具合が頻発すると、開発遅延の主な原因となります。
そのためには事前検討がとても重要だということがよくわかりました。
現行機のドキュメントだけでなく「iRES」によるリバースエンジニアリングで、置き換え開発に必要な情報や課題を揃えること、機能の等価証明の評価環境を用意すること…これらが超重要！！ですね！
現行機のドキュメントだけでなく「iRES」によるリバースエンジニアリングで、置き換え開発に必要な情報や課題を揃えること、機能の等価証明の評価環境を用意すること…これらが超重要！！ですね！
その通りです。当社でも昔は置き換え開発に苦労したものです…。実は、社内での置き換え開発の失敗から学び、「N-Process」は生まれたんですよ。あぁ、あの頃を思い出すだけで鳥肌が立ちます…。
やっぱり、冒頭の怖い話は本当にあった話だったんですか？！
いやいや、誰もいなくなったりしていませんから安心してください。
ともあれ、当社には組込みソフトウェアの技術者が多く在籍しています。新しいＣＰＵ置き換えサービス「N-Process」により、置き換え開発の不安を解消し、開発を成功させることができると自信を持っています。
ともあれ、当社には組込みソフトウェアの技術者が多く在籍しています。新しいＣＰＵ置き換えサービス「N-Process」により、置き換え開発の不安を解消し、開発を成功させることができると自信を持っています。
困っているお客様には、ぜひこのサービスを知っていただきたいですね！手戻りのない、安心して進められる開発の未来がここにあるのですから！
そうですね、EOL対応でお悩みの方は、ぜひ一度私たちにご相談いただきたいです。お気軽にご相談ください！
下記のページでも「N-Process」を紹介しています。
こちらも併せて是非ご覧ください！
こちらも併せて是非ご覧ください！
次回のブログ更新は6月を予定しています。
お楽しみに！
お楽しみに！
- ※記載されている会社名、製品名は、各社の商標または登録商標です。
- ※ここに記載されている仕様、デザインなどは予告なしに変更する場合があります。
