駆け出し組み込みエンジニア向け 有益かもしれない情報まとめ

目的

組み込みエンジニアって結構な数いるはずなのに、書籍やネットでの組み込み開発に関する情報が少ないように感じます。
そのため、微力ながらそういった組み込みエンジニア向けに役に立つかもしれない情報をまとめてみました。¹
(主に個人的な経験から得たり/感じたりしたノウハウです)

更新履歴：
2022/4/13 新規作成
2022/4/15 "その3：部品の寿命を考えた設計が必要"を追加
2022/4/16 "その4：フェイルセーフを考慮した設計をする"を追加
2022/4/26 "その10：テレワークや在宅ワークがしづらい可能性がある"を追加

まとめ

設計編

その1：ハードウェア(以降、HW)を意識したソフトウェア(以降、SW)作りが必要

組み込み系なので当たり前と言えば当たり前ですが、メモリやCPUパフォーマンスなどに制約があることが多いです。
もちろん開発対象にもよりますが、小規模な製品だと制約が大きくなりがちな気がします。
極端な場合は、KByteオーダーでプログラムサイズを気にする、というケースもいまだになくはないかなと。
(さすがにここ数年そこまで考慮するケースは稀になった気はしますが)

教訓
使えるHW資源を常に意識しましょう

その2：最近一番読んだドキュメント(文章)は規格やチップの仕様書、というケースがある

場合によりますが、組み込み関係の内容は、一般的に書籍やネットに情報が出回っていることが少ないので、SWを実装するために、規格やチップの仕様書とずっと格闘することになるケースがあります。
そしてそれらは大体英語で、専門用語がふんだんに使われています・・。

教訓
とりあえず英語は学んでおいて損はない

その3：部品の寿命を考えた設計が必要

HWは消耗品なので、寿命を考えた設計が必要になる場合があります。
よくあるのは、Flashメモリの書き込み回数の上限(それ以降は書き込み保証できない上限)で、使用する部品によりますが、数十万回が書き込み上限になることが多いです。

例：
書き込み上限：50万回

・Flashメモリに1秒ごとにデータ書き込み
	Flash書き込み：1回/秒
	Flash寿命：50万秒 = 138時間(5,6日) → 製品として成り立たない

・RAMに1分間データをためて、それを一気にFlashへ書き込み
	Flash書き込み：1回/分
	Flash寿命：50万分 = 8333時間(347日) → 1年に1回取り替えるとか考えれば、製品としてありかも

教訓
部品によって、寿命を考慮する必要があるので、データシートなどで情報収集する

その4：フェイルセーフを考慮した設計をする

フェイルセーフ、つまりシステムに故障や異常が発生したときに安全な動作をするように設計することです。
例えば、私が昔関わっていたオーディオ関係を例に挙げると、よく言われたのは危ないときはミュートしろでした。
いきなりVolume最大の爆音が鳴ってユーザーが驚かないようにするための対策です。

具体例：
・前提：Volume値0～100の範囲で設定できる
・事象：SWがバグったりしてVolume値として127(範囲外の値)が入力された 
　→ 最大値を超えているのでVolume値最大(100)に丸め込み or 範囲外の値だからミュート(0)にする、
　　と考え方はあると思いますが、私は前述した通り、ミュートをフェイルセーフとして考えていたため、基本後者で対応していました

教訓
システムに応じたフェイルセーフを考慮した設計をしましょう

テスト編

その5：シミュレーターで動いたから製品でも動くだろう、は大体動かない

テストするのに、シミュレーターやエミュレーター(ICE)などの机上デバッグを使うことが結構あります。
シミュレーターやエミュレーターで動いても、実際の製品では、そこで見つからなかった不具合が見えてくることが多いです(主にHW観点で)。
あくまでシミュレーターやエミュレーターはテストの補助をしてくれるものということをお忘れなく・・。

教訓
早めに実際の製品環境でデバッグしましょう

その6：単体テストで問題ないから、他の機能との結合テストも大丈夫なはず → 大体不具合が出る

他の人が作った機能と結合して動作テストをする場合に多いのですが、モジュール間のIF変数やAPIなどの認識違いなどが原因で、不具合が出てくることがあります。
(ちゃんと設計して仕様書を作っていても結構あります・・。大体設計漏れで意図しないタイミングでIF変数やAPIにアクセスするとかが多い気がします。)

教訓
機能間のIFに関する仕様書はちゃんと認識合わせする(これは当たり前)
その上で早めに結合テストをすることを意識しましょう

その7：開発環境差分で不具合が再現できないことがある

Aさんが使っている環境で発生する不具合がBさんの環境では発生しない、というパターン。
よくあるのは、使っているSWのバージョン、開発ツール/アプリなどのバージョンが違う、といった環境差分で再現できないケース。

教訓
開発の初期段階で使う環境ツール/アプリのバージョンを決めて、基本そこから更新しない
また、どのSWを使ったかの情報は必ず共有する

その8：ヒューマンエラーで不具合解析が進まないことがある

ある不具合が発生したときに、その手順や条件を共有することはいいのだが、Aさんがやった手順や条件設定をBさんが試しても不具合が再現せず、解析できないというケースがあります。
これは、実はAさんがやった手順や条件と違うことをBさんが試していた、ということがよくあります。
(Aさんの伝えミス or Bさんの認識間違いが原因)

教訓
認識違いが起こらないよう、不具合の条件や手順は文字だけでなく、(可能であれば)動画付きで共有する

その他

その9：開発する製品以外にも測定器など機器を扱うことが多い

これは私の経験上なので一般的ではないですが、テストする際にオシロスコープやロジアナ、テスト用の治具を作るのに半田こてを使ったり、と色々機器を扱うことが結構あります。

教訓
教訓というのもアレですが、これらを使うことをなるべく毛嫌いせず慣れましょう
使ってないと普通に使い方忘れます(経験済み)

その10：テレワークや在宅ワークがしづらい可能性がある

開発中の物理的な製品、を扱うことが他の職種に比べて多いため、どうしてもテレワークがしづらいケースがあります。
開発序盤の設計フェーズならいいですが、終盤の評価フェーズになると、出社しないと対応できないことも多いです。

教訓
教訓ではないですが、テレワークしたい人はそれができる環境を整えましょう
オンラインで開発できる仕組みを整える(開発用PCにリモートログインできるようにする)など

1. 今後思いついたら追記するかもしれません ↩