組み込みソフトエンジニアを極めるために必要なこと

背景・目的

自分の仕事は主に、自律移動システムのための組み込みソフトウェア
開発ですが、近頃は計算処理能力が決して高くないコントローラと、
逆にそれなりに処理能力が高いコントローラの両方を扱うように
なっています。
それらのソフト設計・開発をする際に難しいのは、可読性や整備性だけ
でなく、出来るだけ処理を軽くし速く回せるような設計を考える事ですが、
自分は今までそういったノウハウをちゃんと学んだ事がなかったので、
こちらの書籍を読んで勉強する事にしました。

リアルタイムOSから出発して組込みソフトエンジニアを極める[改装版]

作者: 酒井由夫,発行:エスアイビーアクセス発売:星雲社
出版社/メーカー: 星雲社
発売日: 2016/05/01
メディア: 単行本
この商品を含むブログを見る

これ一冊を読み終えたところで、ソフトウェア開発全般について幅広く
一気に学べたと思えたくらい充実した、大変学びの多い書籍だったので、
今回学んだ事をいろいろと紹介したいと思います。

全体の感想

「もっと早くこの本に出会いたかった」というのが率直な感想です。
読む前の予想では、リアルタイムOSの技術的な仕組みについての
説明がメインかと思っていましたが、それ以外にも、リアルタイム性を
意識したソフト設計の考え方や、後の再利用性、そして品質を担保する
ための取り組みまで解説されており、組み込みソフトウェア開発
全体を一気に学べるほど内容が濃いものでした。
ソフトウェアの設計をする際に必ず悩むのはクラスの分割だと思いますが、
機能やデータに基づいて分割するといった一般的なものに加えて、この
書籍では時間的分割という考え方が紹介されます。
設計するソフトウェアの機能全てがリアルタイム性を要求される訳では
ないので、その中でも優先的に速く処理されなければいけない機能と
そうでない機能でクラスを分けるといったもので、こういう考え方も
あるのかと、大変参考になりました。

メモ

超えなければいけないハードルと壁

時間分割のハードル
機能分割のハードル
再利用の壁
品質の壁

リアルタイムOSの基礎

リアルタイムOSの定義は、「応答時間が一定の範囲内にあることが
保証されているOS」とするのが一般的。
採用するOSを選択するときは、システムに求められる応答性や信頼性、
開発環境構築のしやすさなどを総合的に考えて判断する必要がある。
イベントが発生してから定められた時間内(数十マイクロ秒)に処理を完結
しなければいけない処理をハードリアルタイム処理と呼ぶ。
数十ミリ秒程度の時間遅れが許される処理をソフトリアルタイム処理と呼ぶ。

タスクスタック領域の見積り

タスク起動中にどれくらい関数がネストするか、また、タスク起動中に
割り込みがいくつ入り、割り込みハンドラの中でどれくらいスタックを
使うかを計算して、タスクスタック領域の大きさを見積もる必要がある。

www.uquest.co.jp
www.uquest.co.jp

タスクの状態遷移

リアルタイムOSはタスクの状態を変え、最も優先度の高いタスクをCPUに
割り付けることで、リアルタイム性能を確保しつつ、単一のCPUの上で
疑似並列処理を実現している。
basics.k-labo.work

同期・通信

同期、通信、時間待ちといった他タスクとの連携、タイマー制御を一連の
流れでコードを書くことが出来るのが、リアルタイムOSの最大のメリット。
セマフォとは、リアルタイムOSにおける有限な資源を管理するための
カウンタとなる。

fielddesign.jp

時間待ちを要求してから、OSが使用しているタイマー割り込みが発生する
までの時間が時間待ちの誤差になるという事に注意する。

ベクターテーブル

割り込み要因が発生したときにジャンプする割り込み処理アドレスのテーブル。
CPUによって配置が違うが、多くはメモリの最上部に配置される。

www.renesas.com

スループット要求

一定時間内に処理される情報量の要求。
スループットを要求される機能的独立性を持った複数のモジュールが、リアル
タイム性を要求されているモジュール群の動きを邪魔しないような仕組みを一つ
のCPUで実現しなければならない。

codezine.jp

オブジェクト指向設計

システム設計の際は、アクティブオブジェクトが不必要に増えないようにする。
パッシブオブジェクトは受動的にしか動かないのでテストしやすいし、再利用
もしやすい。

www.ibm.com

ドメインは入れ物であり、実態はドメイン(パッケージ)の中に入る複数の
クラス(モジュール)となる。
ドメイン間の依存関係は点線の矢印で表し、相互依存にならないように
ドメインの分割を考える。
システム全体を俯瞰するには、クラスよりも大きな粒度の入れ物が必要と
なり、それがドメイン(=パッケージ)である。
変わりやすい部分と変わりにくい部分を分離する。

機能的分割と時間的分割のすり合わせ

機能的分割を行った後で、時間的な要求について見直す。
性能実現と機能的独立性のバランスを考えた場合、オブジェクト指向設計の
デザインパターンを使うのではなく、組み込みのドメインにカスタマイズした
パターンを組織で共有することも必要になる。
性能実現と機能的独立のバランスポイントをずらした結果、顧客満足を下げる
ことになっていないかどうかを確認することを忘れない。

体系的な再利用

体系的なソフトウェア再利用戦略であるソフトウェアプロダクトラインは、
カーネギーメロン大学ソフトウェア工学研究所が長年研究を進めている。
www.sei.cmu.edu
場当たり的な流用と体系的な再利用の違いについて理解し、その違いを
周りのエンジニアやマネージャに説明できるようになることが重要。

ドメイン分析

ユーザーニーズに重点を置きながら、システムで何が成されるか、どの
ようなモジュールに分割するか、というテーマについてドメイン(問題領域)
をベースに考える。
モジュール同士の結合が非常に強くなっている場合は修正が必要になる。
ドメイン間のインターフェース部分の修正だけに注力を注ぐ。
コア資産となるドメインから順に内部構造を見直すというアプローチを
製品開発のたびに繰り返す。
ドメイン分析，ドメインモデル，ドメイン知識

品質向上の考え方

求められる安全性や信頼性に優先度を付けて、大きなユーザーリスクから
順番に取り除くようなアプローチを取っていく。
不具合ののもとを作り込む原因となっている人間の活動をコントロールする。
機能設計、内部設計、詳細設計というフェーズにおいて「不具合を作り込ま
ない努力をしている」という意識を持つ。

完全なプログラムとは

要求仕様を漏れなく記述した仕様書に基づいて作成した全ての入力パターンに
基づくテストケースを、対象となるプログラムに通した際の予想結果とテスト
結果が全て一致したプログラム。

関数の完成度を高める手順

関数の要求仕様を明確にしドキュメント化する。
関数に対する入力と入力に対応した出力を分析する。
入力がグルーピングできる場合はその境界値を摘出する。
境界の内と外を含んだテストケースを作る。
正常入力、異常入力のサンプルを作る。
作成したテストケースを関数に通し、期待値と一致するかどうかを確認する。