
連載企画:ラズパイ試作からマイコン量産への進め方
第1回:開発ステップとシステム設計段階の留意事項
A) 開発ステップ
マイコンで量産する製品を開発する際、初めて使うデバイスや、まだ機能確認をしていないアルゴリズムなどのPoC(Proof of Concept:概念実証)を、マイコンではなくRaspberry Pi(以降ラズパイ)などを使って短期間で効率よく行いたいということがよくあります。
ラズパイはLinux上で動作する高性能なシステムであり、メモリ容量や処理能力に余裕があります。一方、マイコンはリソースが限られ、リアルタイム制御が前提となります。この違いを考慮しないPoCは、マイコンへの移植時に大きな問題を引き起こします。
確かにラズパイを使えばPoCは短期間にできます。しかし、手っ取り早くできるからとラズパイの機能をいろいろ使って検証を実行してしまうと、ラズパイでの試作結果をマイコンに移植する場合、予定外の長時間の開発になったり、最悪マイコンでは実現できないということになったりしてしまうことがしばしばあります。
このように開発計画に大きな影響を与えないようにするためには、図1のようなステップで、システム設計の段階からPoCとマイコンへの移植を考慮することが重要です。以降では、このそれぞれのステップで留意すべきことについて解説していきます。
図1 開発のステップと留意事項
B) システム設計段階の留意事項
ここではまず製品コンセプトを決めます。 目的、機能、対象ユーザー、使用環境などを想定して、性能要件や環境条件、入出力、機能、さらにコストなどの制約条件を決めていきますが、いずれも通常のシステム設計の手順で進めます。
この段階では設計のみを行いますが、あくまでもマイコンを使った最終製品を意識して決めていきます。主に決めるべき内容は次のようになります。
- 機能要件(何をするか)
- 性能要件(速度・精度・応答時間)
- 環境条件(温度・湿度・振動・電源)
- 制約条件(コスト・サイズ・消費電力)
- 保守条件(使用年数、メンテナンス方法、更新方法)
ここで曖昧なまま先の段階に進むと、PoCでは動いたがマイコンでは動かないとか、量産コストが合わないとか、信頼性が足りないとかという根本的な失敗につながります。実際の開発でも、この段階の不備が後工程で数倍の工数増加につながることがしばしばです。
これらの制約条件のもとでハードウェアとソフトウェアのシステム設計を進めます。
(1) ハードウェアシステム設計
ハードウェアシステム設計での留意点は次のようになります。
- マイコン化を見据えて部品を選択し、要求仕様が満足できるかを確認する
- 最終製品の全体ハードウェア構成をブロック構成図にする
- 新規デバイス、新規インターフェースを明確にする
- 開発が必要なインターフェースをブロック図に含める
- 性能、必要なモジュール、ピン数などからマイコンを選択する
- 供給電源の確認、ノイズ、安定度、瞬断の有無などの確認
ブロック構成図を作成することで、抜けのない設計となりますし、新規開発が必要な部分も明確になります。さらに図にすることで、チーム内の認識を統一することができます。
PoCでラズパイを使う前提の場合、新規デバイスをラズパイに接続する方法も、この時点で確認しておくことが必要です。PoCの段階で接続が難しくなって評価できないということが無いようにします。
(2) ソフトウェアシステム設計
ソフトウェアシステム設計での留意点は次のようになります。
- 最終製品の全体の機能を分割しブロック構成図にする
- ベアメタル構成か、RTOSを使う構成かを決める
- 新規アルゴリズム部や新規デバイスドライバ部は分離し独立化する
- PoCで検証が必要な部分を明確にし、ハードウェア依存部分を抽象化(HAL:Hardware Abstraction Layer)し、移植しやすい構造とする
ソフトウェアもブロック構成図とすることで、開発が必要な部分と新規に検証が必要な部分が明確になります。そしてそれぞれの開発規模も推定が可能になりますから、全体の開発量を推定することができるようになります。これでチーム内の分担の割り振りも可能となります。
ブロック図を作成する段階で、全体構成をベアメタル構成とするか、RTOSを使う構成とするかを決める必要があります。センサ取得、通信処理、UI処理など複数の処理を同時に安定して実行する必要がある場合には、RTOSの採用を検討します。どちらの構成にするかにより、設計が全く異なることになりますから、システム設計の早い時点で決めることが必須です。どのRTOSを使うかの選択も早めに決めます。
(3) 新規開発部の代替案の作成
システム設計段階で想定された新デバイスや新機能、新アルゴリズムなどがある場合は、PoC試作の段階で検証します。
最悪PoC試作の段階で仕様を満足しなかったり、実現不可能となったりした場合には、システム設計まで手戻りすることになりますから、その最悪のケースも想定して、アルゴリズムを軽量化したり、デバイスを変更したりなどの代替案も組み込んでおくことが必須です。
次回はアーキテクチャ設計での留意事項を解説します。
PDF 資料請求
連載企画_Raspberry_1:開発ステップとシステム設計段階の留意事項
著者プロフィール
後閑 哲也 Tetsuya Gokan
| 経歴 |
1971年 東北大学卒業後 大手通信機メーカにて各種の制御装置を開発 2003年 有限会社マイクロチップ・デザインラボ設立 |
|---|---|
| 現在の活動 |
|
| 書籍 (技術評論社) |
|
連載企画「開発ステップとシステム設計段階の留意事項」リンク
- 第1回:組み込みシステムのシステム設計とは
- 第2回:アーキテクチャ設計段階(9月公開予定)
- 第3回:ラズパイによる PoC 試作段階(10月公開予定)
- 第4回:マイコン試作、量産開発段階(11月公開予定)
