前回の講義のおさらい 組み込みソフトウェア工学 第 3 回組み込みシステムアーキテクチャ 開発プロセス 製品を開発する上での必要なプロセス 何を作るか ( 要求, 戦略 ) どうやって作るか ( 開発プロセス ) 開発で必要な要因 ( 人物金情報 ) スケジュールと仕様書 本日の内容 組み込みシステムアーキテクチャ 組み込みシステムにおけるソフトウェアを作成する上で必要な構成要素をどのように考えるかについて理解する 組み込みで必要な技術要素 構成要素 ブロック図 状態遷移図 組み込みで必要な技術は何か MPU( マイクロプロセッサ ) に関する知識 MPUの種類 CISC : Z80, 8051, 8085 RISC Core : MIPS, ARM, PowerPC, NIOS With IO : PIC, H8, SuperH, AVR 色々なプログラミング言語の知識 ( クロスコンパイラ ) ASM, C, C++, Java RTOS (Real-Time OS) の知識 itron, VxWORK, OS-9, QNX, Linux, WindowsCE メモリ管理技術 (MMU : Memory Management Unit) 周辺装置の使い方その他...
構成要素で必要なことは 組み込みシステムアーキテクチャ どんな構成要素があるのか? どんな製品を作るのか? 製品のコンセプト, アーキテクチャ その製品はどのような要素で成り立つのか? 機能毎のブロック図 ハードウェアおよびソフトウェアのブロック図 状態遷移図 処理単位の状態の変化とイベント 直感的に分かり易くするために図で状態を表す 製品に対する設計思想 ( 哲学 ) 専用の機能を実現 ハードウェアとソフトウェアが緊密に統合されたコンピュータシステム 特定のアプリケーション用に構築 ハードウェアとソフトウェアのコンポーネントは高度に統合される 開発モデルはハードウェア / ソフトウェアの共同設計モデルとなる. アーキテクチャが無いとどうなるのか? 何を拠り所としてシステムを作るのか 開発途中で思いつきでどんどん変更されると... 組み込みシステムアーキテクチャ どんな製品を作るのか 専用の機能を実現つまりバグだらけの製品となる ハードウェアとソフトウェアが緊密に統合されたコンピュータシステム 特定のアプリケーション用に構築少しの変更でも他に与える影響が ハードウェアとソフトウェアのコンポーネントは高度に統合される大きくなりれる. 開発モデルはハードウェア, バグや製品自体が動 / ソフトウェアの共同設計モかない物が出来上がってしまうデルとなる. 変更の部分が多岐に渡る可能性があるため, システムの完成が遅 アーキテクチャが無いとどうなるのか? 何を拠り所としてシステムを作るのか 開発途中で思いつきでどんどん変更されると... 遅れないように無理をすると潜在的なバグが多くなる可能性がある. 補助記憶装置を例に 容量 アクセスタイム インターフェース 大きさ 信頼性 コスト 設計の前提となる要求は より大容量に 単位面積辺りの記憶容量 より速く 回転の高速化 シリアル ATA 3.5 インチ S.M.R.T 信頼性技術 より安く
どんな製品を作るのか 実際の HDD はどうなっているのか 補助記憶装置を例に 容量 アクセスタイム インターフェース 大きさ 信頼性 コスト 設計の前提となる要求は より大容量に 単位面積辺りの記憶容量 より速く 回転の高速化 シリアル ATA 3.5 インチ S.M.R.T 信頼性技術 より安く これらから全体のアーキテクチャを考え, その後各々の技術的な要素を検討していく VCM VCM : Voice Coil Motor スピンドルモータ磁気 磁気 データの読み書き 磁気の動き制御 モーターの動き制御 記録媒体 スピンドルモーター 全体を動かすソフトウェアの存在 電子回路基板 データの送受信 HDD の簡略図 ブロック図 Spindle 電子回路基板 Pre-amp VCM Buffer Memory channel HDC ATA Motor Driver 簡略図では個々の機能は分からない ブロック図とは 機能単位を四角のブロックで表示し データや制御の流れを表わすのに利用される ブロック図の必要性 一目で全体像を描き, 理解する 全体のアーキテクチャから機能毎への細分化 ハードウェア / ソフトウェア同士の関わり合いの理解 機能ブロックに分けて考えることの必要性
機能を並べただけのブロック図 データの流れを追加したブロック図 データの圧縮 リセット メモリ データの増幅 電源制御 データ信号処理 データの圧縮 データの増幅 VCM 制御 モーター モーター制御 データ信号処理 メモリ リセット VCM 制御 電源制御 モーター制御 モーター 何があるかは分かるが, との関係が不明で, 以外のブロックがどの様に関わるかも分からない. ハードウェアがどのような構成になっているかは分かる. しかし, ソフトウェアをどの様に実装するかが不明 データの流れを追加したブロック図 ブロック図は... メモリ データ信号処理 データの圧縮 データの増幅 ハードウェアがどのような構成をしているかが理解できる ソフトウェアエンジニアにとって詳細の回路図を理解する必要はない リセット VCM 制御 電源制御 モーター制御 モーター と関連する部分がソフトウェアが関係する部分ソフトウェアとして が関連する部分のみに着目すれば良い ソフトウェアをどのように設計して良いかはハードウェアのブロック図だけでは分からない しかし に関する部分についてソフトウェアが関連することは分かる ハードウェアに依存する部分と依存しない部分とに分けて, ソフトウェアのブロック図を考えてみる
ソフトウェアブロック図 ソフトウェアブロック図は 1 つの機能として管理可能 タイマ管理 矢印はシステムコールや関数の呼び出し 全体管理 割込み RAS 1 つの機能として管理可能 ソフトウェアがどの様に構成されているかが分かる どの様な機能をソフトウェアのモジュールとして作成すれば良いかを考えられる HW メモリ管理 メモリ データ処理 HDC IF 管理 制御 制御 ソフトウェアを機能毎に分割し, うまく HW と関係させる単純に細かい機能をタスクするのでなく, 集約して扱えるものを探す RAS : Reliability, Availability and Serviceability( 信頼性 可用性 保守性 ) 全体管理 どのような OS を使うのか メモリ管理 効率の良いメモリの使用方法 データ処理 データの圧縮, 誤り訂正 IF 管理 PC からの命令 データの送受信処理 タイマ管理 各タスクに必要な時間 割込み処理 どの様な異常処理があるか RAS 信頼性に関する情報 制御 指定された位置への移動 制御 ソフトウェアブロック図は 状態遷移図とは.. ソフトウェアがどの様に構成されているかが分かる どの様な機能をソフトウェアのモジュールとして作成すれば良いかを考えられる 全体管理 どのようなOSを使うのか メモリ管理 効率の良いメモリの使用方法 データ処理 データの圧縮, 誤り訂正 IF 管理 PCからの命令 データの送受信処理 タイマ管理 各タスクに必要な時間 割込み処理 どの様な異常処理があるか RAS 信頼性に関する情報 制御 指定された位置への移動 制御 モジュール単位のプログラム状態の変化に合わせた処理が分からない 状態遷移図の作成 基本的な挙動の定義 例外パターンや異常処理の定義 システム全体のプロセスやタスクなどの処理単位のプログラムの状態の変化とその状態変化を引き起こすイベントについてまとめたもの 状態が遷移 ( 移動 ) することを分かり易くした図
自動販売機の状態遷移図例 自動販売機はお金が入れられるのを待っている 120 円以上のお金が入れられたらランプを点灯する 投入金額が 120 円未満のときは何も起こらず 待っている ランプが点灯している時にボタンが押されると商品を出す もし残金が 120 円以上残っていたら再びランプを点灯する 残金が 120 円未満の場合は お釣りを出す また ランプが点灯している時にお釣りを出す操作がなされたら お釣りを出す 自動販売機の状態遷移図例 非常に簡単に書くと... お金が入れられた [ 投入金額 120 円 ] 商品が出た [ 残金 120 円 ] ランプ点灯 ボタンが押された 選択された商品を出す 電源オン お金が入れられるのを待つ おつりを出す操作がなされた 商品が出た [ 残金 <120 円 ] お金が入れられた [ 投入金額 <120 円 ] おつりを出す HDD の状態遷移図 ブロック図, 状態遷移図 データの受信 データは全部受信していない データの送信 データは全部送信していない データの受信命令 全部受信 全部送信 データの送信命令 データの読み込み命令 データの読み込み 初期化 リセット信号あり 命令がない 待機中 全部読み込んだ データは全部読み込んでない 全部書き込んだ リセット信号がない 電源オン データの書き込み 指定の回転数 指定の位置へ データの書き込み命令 データは全部書き込んでない 指定の位置 一定回転数でない の回転の移動 指定の位置でない ハードウェアブロック図 どの様なハードウェアであるかがわかり, システム全体のハードウェアのアーキテクチャが分かる ソフトウェアブロック図 ソフトウェアとしてどの様なモジュールが必要かがわかり, 全体の構成と関わるソフトウェア技術についてわかる 状態遷移図 システム全体がどの様に動くかがわかり, バグの少ないソフトウェアを作ることが可能となる これら 3 つの図を作成することでシステムとしてのアーキテクチャが理解可能となる
他の技術との融合 まとめ ブロック図の理解や状態遷移図の作成には色々な知識が必要となる ブロック図の理解には 電子回路 制御工学 メカトロニクス工学 状態遷移図の作成には オペレーティングシステム プログラミング技術 インターフェース技術 通信工学 組み込みシステム デジタル信号処理 ソフトウェア工学 マルチメディア技術など そして, 創造性, 経験が必要 信頼性工学 ヒューマン IF 工学など 製品に必要な構成要素を考える 構成要素とブロック図の必要性 ハードウェアブロック図 ソフトウェアブロック図 状態遷移図 ソフトウェアの処理単位毎の状態の変化 課題 : 要求定義書の評価 要求定義書の評価 本日提出してもらった他の人の要求定義書を見て評価を行う ( 要求定義書提出者のみ ) 評価の学籍番号に評価者の学籍番号を記載 以下の 5 項目について 5 段階で記入すること. なお評価は要求定義書に直接書き込むこと 1 概要 構想 2 機能の満足度 3 入出力仕様 4 品質 5 実現度 なお後日教員も同様に評価を行います. 提出 : 次回の講義の時に要求定義書を集めます この 5 項目について 5 段階で評価を行うここに直接数値を書き込む 評価者の学籍番号を記載