Comments
Description
Transcript
組込みソフトウェア開発課題への挑戦 ～統合化
CESL 組込みソフトウェア開発課題への挑戦 ～統合化～ 渡辺 政彦† 組込みシステムの規模増大により，コードに代わってモデルが多用されるようになってき ている．様々なドメイン，工程で作成されるモデルが散乱することは望ましくない．そこで モデルの統合化をどうすべきかを提言する．本提言では次の３つの統合化モデルについ て述べる．（１）制御系モデルと組込み系モデル （２）構造モデルと振舞モデル （３）バリ エーションモデルと状態遷移モデル Challenge to embedded software development problem –Integrated Modeling– MASAHIKO WATANABE† The model comes to be used in place of the code because of the scale increase of the embedded system. It is not preferable to scatter the models developed in various domains and the processes. Then, it proposes how to be integrated of the models. The following three models of integration are described in this proposal. (1)Control system models and Embedded system models (2) Structural models and Behavior models (3) Variation models and State transition models 構造モデルを表現する何らかの記述体系には，タ スク関連図，モジュール関連図，そしてブロック関連図 などがある．構造モデルは構造に対する性質・共通 性・本質に着目し，振舞いに対する性質を排除する． 1. はじめに 組 込 み ソ フ トウェ ア の規模が急拡大している(図 1)[1]．規模の拡大に対するソフトウェア工学がとるアプ ローチの１つが抽象化である．組込みソフトウェアの規 模が大きくなり，マイコンが解読する機械語から，人が 解読できるアセンブラ言語へ抽象度を上げた．さらに ソフトウェアの規模が拡大すると，アセンブラ言語から 高級プログラム言語である C，C++，そして JAVA など へ抽象度を上げてきた．そして，現在，高級プログラム 言語で記述する行数が急増している． このため，さらなる抽象化として登場するのがモデ ルである．モデルとは現実世界の問題領域を抽象化し， なんらかの記述体系で表されたものである(図 2)[2]． 大辞林で抽象の意味をひくと，『事物や表象を、ある 性質・共通性・本質に着目し、それを抽(ひ)き出して把 握すること。その際、他の不要な性質を排除する作用 （＝捨象）をも伴うので、抽象と捨象とは同一作用の二 側面を形づくる』とある． すなわち，組込みシステムアーキテクチャの問題領 域から構造の性質を抽出し，なんらかの記述体系で示 されたものが「構造モデル」となる． 図 1 急拡大する組込みソフトウェア また，振舞いモデルを表現する何らかの記述体系 には，状態遷移図，状態遷移表，シーケンス図，そし †キャッツ組込みソフトウェア研究所, CATS Embedded Software Laboratory 1 Copyright CATS 2009 [2009 年 8 月 18 日] CESL てタイミング図などがある．振舞モデルは振舞いに対 する性質・共通性・本質に着目し，構造に対する性質 を排除する． さらに，組込みシステム要求仕様の問題領域からバ リエーションの性質を抽出し，なんらかの記述体系で 示されたものがバリエーションモデルとなり，フィーチャ －図などの記述表現がある． 組込みシステムの問題領域から抽出すべき性質は たくさんあるので，上記の３つだけでなく，数多くの種 類のモデルが必要となるであろう． 現実世界の 問題領域 制御系設計では，モデルは一般的にプラントモデ ルを示す[3]．本稿では制御対象を表すものをプラント モデル，制御則を表すものをコントローラモデルと呼ぶ． 制御系設計では，制御対象，制御目標，制御量を明 確にしたのち，どのようなセンサとアクチュエータをどこ に配置するかを検討する． 組込み系モデルは，上流工程の要求から下流工程 の実装まであるプロセスのアクティビティごとにモデル が存在する． どのような製品を開発するかが要求モデルに記述 される．例えば自動車や家電機器には，多品種多オ プション製品の仕様がある．これを上手く整理しないと， 似て非なるソフトウェアを大量に開発しなければならな い．多品種多オプションの問題領域を抽象化するのが バリエーションモデルである． 近年の組込みシステムはネットワークやバスによっ て構築される分散システムであることが多い．このため， アーキテクチャの良し悪しが，システム全体の性能に 影響する．システムの物理構造性質に着目したモデル をシステムアーキテクチャモデルと呼ぶ． 物理構造とは切り離して，機能やサービスを抽象化 したものが論理構造モデルである．コンポーネント，オ ブジェクト，プロセス，スレッドもしくはタスクなどの配置 を示すものが組込みソフトウェアモデルである． モデル 抽象化し なんらかの 記述体系で表す 自動化 コード 実機 図 2 モデルとは 2.2. 課題 現在，組込み系モデルが抱える課題の１つに，モ デル間における相互作用の複雑化がある． 本来，モデルは，機能独立性を有しているものであ る．機能独立性とは 1970 年初頭から Parnas，Wirth， Stevens，Myers，そして Constantine らの研究により確 立された抽象化と情報隠蔽を意味する基本概念であ る．機能独立性とは，モジュールを「ただ１つの目的を 持った」機能を実現するように開発し，他のモジュール との過度の相互作用を「回避」することによって実現さ れる[4]． 機能独立したモデルを組合せることで，システムの 機能や振舞いを実現するのである．さらにシステムは 固定化されたものではなく，常に進化する． このため，どんなに機能独立性を高めても，より高 度なシステムを実現するために，独立性を高めたモデ ルを複雑に相互作用させることになる． 自動車では車載 LAN を伝送路として，機能独立性 が高い ECU が相互作用し，統合安全機能などの高次 元なサービスを提供する．家電機器も同様にホームネ 2. 制御系モデルと組込み系モデル 2.1. 位置付け 本稿における制御系モデルと組込み系モデルの位 置付けを図 3 に示す．当然ではあるが，図に示すモデ ルは１つの例であり，対象とする問題領域ごとにモデ ルの構成は変わる． 組込み系モデル 制御系モデル 要求モデル・バリエーションモデル センサ コントローラ 安全制御サービス 車種グレード 低 中 保守グレード 高 低 中 制御対象 （エンジン, ドライブトレーン） 環境 （外気温, 負荷, 運転者…） 高 システムアーキテクチャモデル マルチメディア・通信ユニッ ト 安全センサユニット ON/OFF センサ 濃淡 センサ (OUT) 安全・保守ユニッ ト 濃淡 センサ (IN) 組込みソフトウェアモデル 安全サービス共通モジュ ール (p1,p2…) センサ監視共通 モジュール(p1,p2…) 安全制御共通モジュール (p1,p2…) タイプ タイプ タイプ タイプ A B C D ON/OFF センサドライバ 濃淡量 センサドライバ 制御方式 A 制御方式 B 制御方式 C マルチメディアユーザI/F (p1,p2…) 無線回線I/F (p1,p2…) 点検整備DB I/F (p1,p2…) 図 3 制御系モデルと組込み系モデル 2 Copyright CATS 2009 [2009 年 8 月 18 日] CESL ットワークに接続することで，独立していた家電機器の 機能に相互作用を起こし，新しい付加価値を創出す る． 組込みシステムでは，高付加価値のある機能の提 供に加えて，低コストでそれらを実現することが求めら れる．そのためにモデルの個別最適化からシステム全 体からの最適化によって個別のモデルを洗練する必 要がある． 制御モデル 要求モデル・バリエーションモデル ① 安全制御 センサ コントローラ 制御モデル 車種グレード て良いが，実現コストは安価であることが設計条件で ある．「中」車種グレードでは，制御は濃淡と量のフィ ードバック制御で，制御粒度は細かいが，制御速度は 遅くて良く，実現コストは高価ではないことが設計条件 である．「高」車種グレードでは，濃淡量センサを採用 し，センサからフィードバック制御することで，濃淡の量 の制御で，制御粒度は細かく，かつ制御速度は速い が，実現コストは高くても可である． 制御系モデルで複数のバリエーションを扱うことは， 制御系モデルが複雑化することを意味する．一方で， バリエーションをバリエーションモデルで扱い，制御系 モデルは，あくまで単一バリエーションにすることで， 制御系モデルの複雑化を防止できる．この場合，バリ エーションモデルと制御系モデルの間に依存関係が 生じ，この関係をどのように管理するかが課題となる． 保守グレード センサ 制御対象 （エンジン, ドライブトレーン） コントローラ 制御対象 （エンジン, ドライブトレーン） 環境 （外気温, 負荷, 運転者…） 制御モデル 低 中 高 低 中 高 センサ コントローラ 制御対象 （エンジン, ドライブトレーン） 環境 （外気温, 負荷, 運転者…） 環境 （外気温, 負荷, 運転者…） システムアーキテクチャモデル マルチメディア・通信ユニット 安全センサユニット 濃淡 センサ (OUT) ② ② ON/OFF センサ 濃淡 センサ (IN) 要求モデル・バリエーションモデル 安全・保守ユニット 安全制御 ③ 車種グレード 組込みソフトウェアモデル 低 安全サービス共通モジュール (p1,p2…) センサ監視共通 モジュール(p1,p2…) 安全制御共通モジュール (p1,p2…) タイプ タイプ タイプ タイプ A B C D ON/OFF センサドライバ 濃淡量 センサドライバ 制御方式 A 制御方式 B 制御方式 C 中 濃淡量センサを入力と出力に配置した フィードバック制御 制御粒度：細 制御速度：速 コスト：高 保守グレード 高 低 中 高 マルチメディアユーザI/F (p1,p2…) 無線回線I/F (p1,p2…) #3 制御モデル ON/OFFのみの フィードバック制御 制御粒度：荒 制御速度：遅 コスト：安 点検整備DB I/F (p1,p2…) 図 4 モデル間相互作用 濃淡の量の フィードバック制御 制御粒度：細 制御速度：遅 コスト：中 #1 制御モデル 本稿で提言するモデル間で起こる 3 つの相互作用 を図 4 に示す． (1) バリエーションモデル－制御系モデル (2) バリエーションモデル・制御系モデル－組込み ソフトウェアモデル (3) 組込みソフトウェアモデル－システムアーキテク チャモデル モデルの種類はたくさんあるが，上記 3 つに関する 相互作用課題への解決方法は，モデルの種類に関係 なく広く適用できると考える． センサ コントローラ 制御 対象 （エンジン, ドライブトレーン） 環境 （外気温, 負荷, 運転者…） センサ コントローラ 制御対象 （エンジン, ドライブトレーン） 環境 （外気温, 負荷, 運転者…） #2 制御モデル センサ コントローラ 制御対象 （エンジン, ドライブトレーン） 環境 （外気温, 負荷, 運転者…） 図 5 バリエーションモデル―制御系モデル 2.2.2. バリエーションモデル・制御系モデル－組込み ソフトウェアモデル 組込みソフトウェアモデルには，下流工程に実装を 意識したモデルがある．一般的に実装モデルでは， ROM/RAM リソース削減や，テスト工数削減，保守性 向上のために，モジュールの共通化を行う．実装上の 制約から制御系モデルの構成要素が，組込みソフトウ ェアでは同じ構成とはならない場合が多くある．このた め，制御系モデルと組込みソフトウェアモデル間の依 存関係が複雑化し，追跡可能性が取り難くなる．同様 に，バリエーションが実装モデルの広範囲に影響を与 えることから，バリエーションモデルと組込みソフトウェ アモデル間の依存関係が複雑化し，追跡可能性が取 り難くなる． バリエーションモデル・制御系モデルと組込みソフト ウェアモデルの例を図 6 に示す．コントローラモデルは， プラントモデルを制御対象として，制御目標を達成す 2.2.1. バリエーションモデル－制御系モデル 単一の制御系モデルから，多品種多オプションの 制御系モデルへの変化は，バリエーションモデルと制 御系モデルとの間で起こる相互作用の管理が課題と なる． バリエーションモデルと制御系モデルの相互作用 について図 5 に示す．車種グレードを 3 種類，「低」， 「中」，「高」と設定することで，それぞれの車種グレード 向けの制御系モデルを作成する． 「低」車種グレードでは，制御は ON/OFF のみのフィ ードバック制御で，制御粒度は荒く，制御速度は遅く 3 Copyright CATS 2009 [2009 年 8 月 18 日] CESL るための制御量を計算する．組込みソフトウェアでは， コントローラモデルの機能に加えて，センサへのアクセ ス方法，故障の監視や故障時の対応などが含まれる． このため，制御系モデルで記述された１ブロックは，組 込みソフトウェアモデルでは複数のモジュールに分散 することが多い． 同様にバリエーションモデルは，コード一元管理下， #ifdef 文がコード中に散在する．構造化プログラミング によって，goto 文スパゲティ構造を駆逐したが，#ifdef 文スパゲティ構造が進行しているようだ．このため，コ ードレベルの#ifdef 文によるバリエーション対応から抽 象度の高いモデルレベルでのバリエーション対応が期 待される．そこで，バリエーションモデルと他のモデル との相互作用の明確化とその管理方法が課題となる． システムアーキテ クチ ャモデル センサ コントローラ 安全制御 ON/OFF センサ 制御モデル 中 保守グレード 高 低 中 センサ 高 センサ コントローラ 制御対象 （エンジン, ドライブトレーン） 制御対象 （エンジン, ドライブトレーン） ON/OFF センサ コントローラ 制御対象 （エンジン, ドライブトレーン） 安全サービス共通モジュール (p1,p2…) 安全制御共通モジュール (p1,p2…) タイプ タイプ タイプ タイプ A B C D 濃淡量 センサドライバ マルチメディ ア・通信ユニット 制御方式 B 制御方式 C 濃淡 センサ (OUT) 安全・保守ユニット 濃淡 センサ (IN) ② 組込みソフトウェアモデル ③ 環境 （外気温, 負荷, 運転者…） 安全サービス共通モジュール (p1,p2…) センサ監視共通 モジュール(p1,p2…) 安全制御共通モジュール (p1,p2…) タイプ タイプ タイプ タイプ A B C D ON/OFF センサドライバ 濃淡量 センサドライバ 制御方式 A 制御方式 B 制御方式 C マルチメディアユーザI/F (p1,p2…) 無線回線I/F (p1,p2…) 点検整備DB I/F (p1,p2…) 図 7 組込みソフトウェアモデル―システムアーキ テクチャモデル 組込みソフトウェアモデル ON/OFF センサドライバ ① 環境 （外気温, 負荷, 運転者…） ROM/RAMリソース削減のため，テスト工数削減のため，共通モジュール化を行う． 制御方式 A 保守ユニット 濃淡 センサ (IN) 安全センサユニット 環境 （外気温, 負荷, 運転者…） センサ監視共通 モジュール(p1,p2…) 濃淡 センサ (OUT) 安全ユニット システムアーキテ クチ ャモデル 制御モデル 低 マルチメディア・通信ユニット 安全制御ユニット 制御モデル 要求モデル・バリエーションモデル 車種グレード みソフトウェアモデルからシステムアーキテクチャモデ ルにソフトウェアとハードウェアの最適配置の見直し要 求という相互作用が起きる． 例えば，保守ユニット(図 7-①)がメンテナンス時にし か動作しないことから，安全制御機能を安全・保守ユ ニット(図 7-②)に搭載し，ECU の数を減らすことでコス トを削減する．またセンサ系に制御ロジックを搭載しな いことで安全センサユニットのコストも削減する(図 7③)． マルチメディアユーザI/F (p1,p2…) 無線回線I/F (p1,p2…) 2.2.4. モデル間相互作用 制御系モデルと組込み系モデルを少数で開発して いれば，さほど問題にはならなかったが，近年，数十 人から数百人規模で開発することが多くなってきてい る．こうなると，開発の成果物であるモデル間の相互作 用が混沌とした状況に陥る． 複数の問題領域における相互作用問題の例を図 8 に示す． (1) 要求モデル： ・車種グレードに超低価格と超高級を入れたいが， 誰に何をどう伝えるのか(図 8-①) (2) 制御系モデル： ・新しい制御則（精度がでるが速度はやや遅い）を 採用したいが，誰に何をどう伝えるのか(図 8-②) (3) システムアーキテクチャモデル： ・センサのスペックが変更されたが，誰に何をどう伝 えるのか(図 8-③) ・競合がもっと安く，かつ機能が高いものを出した． どこを直すか即時検証をしたいが，誰に何をどう 伝えるのか(図 8-④) (4) 組込みソフトウェアモデル： ・ここをもっとこうすれば，メモリを大量に使わず 点検整備DB I/F (p1,p2…) 図 6 バリエーションモデル・制御系モデル―組込 みソフトウェアモデル 2.2.3. 組込みソフトウェアモデル－システムアーキテ クチャモデル 制御系設計では，コントローラモデルが安定した制 御をするための制御則を設計する．制約を充足する計 算式を算出するための開発プロセスは，イテレーティ ブ開発とインクリメンタル開発のどちらかまたは融合し た開発プロセスとなる． このプロセスを支援する開発環境に，MILS (Model In the Loop Simulation)と HILS(Hardware In the Loop Simulation)がある．MILS や HILS で，理想的な制御則 を求めたとしても，あくまでも理論値であり，実装値で はない．制御系のシミュレーションは浮動小数点で行 われるが，組込み系では，製品コストの制約から浮動 小数点を固定小数点になる場合が多い．また，計算式 の CPU リソース占有率が，故障診断等の制御系以外 の機能実行に影響あるかを検討する．このため，組込 4 Copyright CATS 2009 [2009 年 8 月 18 日] CESL に済むのに，誰に何をどう伝えるのか(図 8-⑤) ・バグがでた．誰に何をどう伝えるのか(図 8-⑥) 制御モデル 要求モデル・バリエーションモデル センサ コントローラ 安全制御 新しい制御則（精度 制御モデル 車種グレードに超 車種グレードに超 車種グレード 保守グレード 低価格と超高級を ① 低 中 低価格と超高級を 入れたい誰に何を 入れたい誰に何を どう伝えるのか 高 低 中 どう伝えるのか きることである．これにより，膨大なモデル間の相互作 用による依存関係を設計作業中に登録できる．設計 完了後に相互作用の依存関係をあらためて登録する ことは実務上難しいと考える．設計時にリポジトリに入 力できることで開発者の作業負担を軽減できる． 統合化の対象となるツールは数多くあるがが，例え ば，制御設計を支援するツール(CACSD: Computer Aided Control System Design)とソフトウェア工学を支 援 す る ツ ー ル (CASE: Computer Aided Software Engineering)を統合化し，依存関係リポジトリを構築す ることで，両領域モデルで起こる相互作用の煩雑さを 低減する． 統合化 CASE ツールを 4 年間利用した場合， 1 ド ルあたりの投資対効果は 25 ドルになるというデータが ある[7]．CACSD ツールと CASE ツールとの統合化は， さらなる投資対効果を期待できる． CACSD ツールと CASE ツールの詳細な連携につい ては，別稿で述べる． ② 新しい制御則（精度 制御対象 がでるが速度はやや がでるが速度はやや （エンジン, コントローラ ドライブトレーン） 遅い）を採用したい誰 遅い）を採用したい誰 に何をどう伝えるの に何をどう伝えるの 環境 制御対象 か （エンジン, （外気温, か 負荷, 運転者…） 制御対象 （エンジン, ドライブトレーン） 環境 （外気温, 負荷, 運転者…） センサ 制御モデル 高 センサ コントローラ ドライブトレーン） 環境 （外気温, 負荷, 運転者…） システムアーキテクチャモデル 安全センサユニット ③ ON/OFF センサ 濃淡 センサ (OUT) マルチメディア・通信ユニット センサのスペック センサのスペック が変更された が変更された 誰に何をどう伝 濃淡 誰に何をどう伝 センサえるのか えるのか ④ 競合がもっと安く機能 競合がもっと安く機能 が高いものを出した． が高いものを出した． どこを直すか即時検 どこを直すか即時検 証をしたい誰に何をど 証をしたい誰に何をど う伝えるのか う伝えるのか 安全・保守ユニット (IN) 組込みソフトウェアモデル ここをもっとこうす ここをもっとこうす れば，メモリを大 センサ監視共通 れば，メモリを大 ⑤モジュール(p1,p2…) 量に使わずに済 量に使わずに済 むのに，誰に何を むのに，誰に何を どう伝えるのか どう伝えるのか ON/OFF センサドライバ 濃淡量 センサドライバ 安全サービス共通モジュール (p1,p2…) 安全制御共通モジュール (p1,p2…) 制御方式 A 制御方式 B バグがでた バグがでた タイプ タイプ A B 誰に何をどう ⑥ 誰に何をどう 制御方式 C 伝えるのか 伝えるのか タイプ タイプ C D マルチメディアユーザI/F (p1,p2…) 無線回線I/F (p1,p2…) 点検整備DB I/F (p1,p2…) 図 8 モデル間その他の相互作用 2.3. 解決方法 モデル間の相互作用問題を解決するためには，モ デル構成要素間の関連を把握できる仕掛けが必要で ある．モデル構成要素は，制御系モデルの場合は各 ブロックである．システムアーキテクチャモデルでは， 例えば車載用コンポーネントベース開発である AUTOSAR[5]を採用した場合，SWC(ソフトウェアコン ポーネント)モデルの各コンポーネント，トポロジーモデ ルの各 ECU となる． モデル構成要素間の関連を把握できる仕掛けを実 現する機構がリポジトリである．一般的にリポジトリの役 割は広範囲で，モデルデータとツールの統合や，モデ ル同士の統合を実現するメカニズムとデータ構造から 構成される[4]． モデルデータとツールを統合するためにはメタモデ ル と い っ た 概 念 が 必 要 に な り ， OMG の QVT(Query/View/Transformation)[6] ， ISO/IEC 15474-1(2002)の CDIF(CASE data interchange format) フレームワークがある．相互作用問題を解決するには， モデルの交換形式より，モデルの依存関係を追跡可 能性が必要になる．モデルの依存関係に特化したリポ ジトリを依存関係リポジトリと呼び，広義なリポジトリと区 別する． 依存関係リポジトリを図 9 に示す．依存関係リポジトリ と要求管理ツールとは，追跡性管理において似ている． 本稿における提言は，統合するモデルを扱うツール同 士を統合し，設計対象が異なるツールでも，同じ操作 感でモデル構成要素の依存関係をリポジトリに登録で リポジトリ登録 リポジトリへ登録 依存関係 リポジトリ 図 9 依存関係リポジトリ 3. 構造モデルと振舞モデル 構造モデルは，実現すべき複雑なシステムから，構 造だけを抽出する．そうすることで，複雑なシステムの 構造に関して，抽象度が上がり，適切な設計対象にな る．しかしながら，実現すべきシステムは，構造だけで は動作しない． 機能が「いつ」，「どのようなときに」実 行されるかについては，構造モデルでは捨象される． 振舞モデルは，システムから動的な性質を取りだす． 動的な性質とは構造モデルで捨象された「いつ」，「ど のようなときに」である．「いつ」とは事象であり，「どのよ うなときに」は状態となり，そして「次のどのような状態に 変化するか」は遷移になる．事象，状態，そして遷移を 表現する表記法として状態遷移図・表がある．本稿で 5 Copyright CATS 2009 [2009 年 8 月 18 日] CESL は状態遷移図・表で表記されたモデルを状態遷移モ デルと呼ぶ． 組込み系モデルで良く用いられる表記法は，状態 遷移図，フローチャート，状態遷移表，タスク関連図， そしてタイミングチャートである(図 10)[8]．エンタープラ イズ系における同様な調査では，組込み系で下位に 位置する UML と DFD が上位になる[9]．組込み系では 上位に位置する状態遷移図，状態遷移表，そしてタイ ミングチャートは，エンタープライズ系ではその他の設 問に置かれる扱いで，かつその使用率は非常に低 い． どのようなモデル表記法を利用するかで，組込み系 とエンタープライズ系の違いが分かるようで興味深い． 最近のエンタープライズ系の不具合は，状態遷移モデ ルによる分析，設計をしていないからなのだろうかとい った推測をしたくなる． 3.2.1. システム システム振舞モデルとシステム構造モデルの相互 作用を図 11 に示す． システムの振舞いを状態遷移モデルで記述したシ ステム振舞モデルが用意されている．システム振舞モ デルからアクションとアクティビティリストを取りだし，ア クション・アクティビティリストを作成する(図 11-①)．列 挙したアクションおよびアクティビティを「いつ」，「どこ で」呼び出し，その後「どうなるか」といった有限状態機 械を動作させる FSM コントローラを用意する． 機械的に抽出されたアクション・アクティビティリスト のアクションやアクティビティに対して共通化や洗練化 を行い，システム構造モデルを導出する(図 11-②)．モ ジュールの共通化，洗練化によって，実装時のリソー ス効率性，試験容易性，保守性等を向上する． 機能の依存関係は結線で示す．機能の実行順位 や呼出関係が明確であれば，矢印を用いて示す．例 では，3 つのモジュールが FSM コントローラから呼び出 される関係で，それぞれのモジュール間の依存関係を なくした機能独立性の高い構造となる． システム構造モデルで作成されたモジュールをシス テム振舞モデルに再配置する(図 11-③)．これにより， システム構造モデルで洗練された機能モジュールとシ ステム振舞モデルとの依存関係が明確化できる． アクション・アクティビティリストとシステム構造モデル とを対応付ける作業を手作業で行う必要はあるが，そ れができれば，後はシステム振舞モデルとシステム構 造モデルとの依存関係を自動的にリポジトリに登録す ることが可能である． 図 10 モデリング手法の利用状況 3.1. 課題 異なるモデル間での依存関係を管理する方法とし て 2 章で述べたリポジトリがある．モデルベースツール 間を統合し，依存関係リポジトリへの登録方法を効果 的にする提言をした．しかしながら，登録する依存関 係そのものが属人的で，開発者によってその依存関 係の定義が多種多様な混沌とした依存関係を管理す ることになる課題がある． システム振舞モデル ■状態遷移表 モデル S E 送信要求 (ホストから) 1 アクション ・ア クティビティリスト 初期 送信中 Entry:タイマを起動する Exit:タイマを停止する 1 2 ドライバに データ送信す る =>2 ホストに ビジーを返す 送信完了 2 (ドライバから) ホストに正常完了を返す =>1 タイムアウト ホストに異常完了を返す 3 (タイマから) FSMコントローラ ホストに異常完了を返す タイ マを起動する =>1 送信要求 (ホストから) 1 送信完了 (ドライバから) 2 タイムアウト (タイマから) 3 ② S E 3.2. 解決方法 構造・振舞モデルの相互作用，および機能・振舞 モデルの抽象度に関する相互作用に対して，設計手 法を設けることで，各モデルにおける依存関係を整理 することを提言する． 設計手法により，属人性を排除することは，モデル 依存関係を自動的にリポジトリで管理する統合化モデ ルベース開発環境の構築に寄与する． ホストにビジーを返す ホストに正常完了を返す 再配置振舞モデル ■状態遷移表 モデル ドライ バにデータ送信する ① 初期 送信中 Entry:タイマ(起動) Exit:タイマ(停止) 1 2 ドライバに データ送信す る =>2 ホストに完了を返 す（ビジー） ホストに完了を返 す（正常） タイ マを停止する システム構造モデル FSMコントローラ ③ =>1 ホストに完了を返 す（異常） ドライ バに データ送信する ホストに完了を返す （ビジー、正常、異常） タイ マ （起動，停止） =>1 図 11 システム 振舞－構造 3.2.2. システム－モジュール システムとモジュールという抽象度の異なるモデル 6 Copyright CATS 2009 [2009 年 8 月 18 日] CESL 再配置振舞モデル 間における「振舞－構造」の相互作用を図 12 に示す． システム構造モデルの構成要素であるモジュール ごとに，振舞モデルを作成する．作成したモジュール 振舞モデルから先ほどと同様に，アクション・アクティビ ティリストを作成する(図 12-①)．抽出したアクションおよ び ア クティビティを 有 限 状 態 機械として動作させる FSM コントローラを用意する． ■ドライバデー タ送信タスク E リセット要求 リセッ ト完了 1 初期 待機中 送信準備完 了待ち Entry: DMA セット Exit: DMA クリア 送信完了待ち Entr y: TXセット Exit : TXクリア 1 2 3 4 ① 正常 2 ⇒待機中 異常 3 リセット要求 //リトライ 4 リセッ ト完了 正 常 2 ⇒待機中 異 常 3 DRV_TX _TSK(R ST) Exit: DMA(CLR) COM_LSI(TX_CLR) 3 4 実装モジ ュール構造モデル FSMコントローラ COM_LSI (RST, TX_SET, TX_CLR) DMA (SET, CLR) DRV_TX_TSK (RST, TX_REQ) データ送信要 求 4 ⇒送信準 備完了待 ち DMA ACK OK 5 ⇒送信完了待ち NG 6 DRV_TX_TSK (TX_REQ) ⇒ COM OK SndMsg() SndMsg(システム制御タ スク,送信完了) 3 DRV_TX_TSK(TX_R EQ) ⇒待機中 ③ Program code //リトライ 図 13 システム－モジュール 振舞－構造 リセット要求 ⇒送信準 備完了待 ち 6 DMAセット TXセット TXクリア 5 ⇒送信完了 待ち DMAクリア 6 データ送信 要求 ⇒待 機中 データ送信要求 SndM sg(システム制御 タスク,送信完了) 3 COM_LSI(TX_SET) Exit: ドライバリセットコマンド発行 NG OK 送信完了待ち Entry: DMA(SET) アクション・アクティビティリスト OK NG COM_LS I(RST) 送信準備完了待ち Entry: 待機中 //リトライ 5 4 //リトライ COM 2 1 FSMコントローラ ドライバリ セットコマン ド発行 データ送信要求 DMA ACK 1 リセット要求 NG S ① 待機中 ② ドライバにデータ送信する 初期 //リトラ イ タイマ （起動，停止） ホストに完了を返す （ビジー、正常、異常） S E FSMコントローラ システム構造 モジュール 振舞 ■ドライバ データ送信タ スク データ送信要求 待機中 //リトライ SndMsg() ⇒ 3 2 図 12 システム－モジュール 1 モジュール振舞モデルから機械的に生成できるア クション・アクティビティリストに掲載されたモジュールに 対して共通化を行い，実装用モジュールを導出する． 実装モジュール構造モデルで作成したモジュールを モジュール振舞モデルに再配置する(図 13-①)． ここまで，システム振舞モデルから取り出されたアク ション・アクティビティが，システム構造モデルのモジュ ールとなり，そのモジュールの振舞モデルから実装用 のモジュールを導出できることを示した． 実装モジュール構造モデルに示されるモジュール には，ミドルウェアや再利用モジュールなどが配置され る ． 外 部 モ ジ ュ ー ル は 破 線 で 示 す ． 図 12,13 の SndMsg がその例である． 実装モジュールは，プログラミングによってプログラ ムコードを作成する(図 13-②)．実装モジュールの規模 がまだ大きければ，さらにモデリングを行い，その後， プログラミングか自動コード生成を行い，プログラムコ ードを作成する． 事象を解析し，当該状態下でモジュールを呼び出 し，状態を遷移させる有限状態機械としてのメカニズム である FSM コントローラのコードを自動生成することが 可能である(図 13-③)． 自動生成コードにより生産性の向上の他に品質の 向上についても期待する声は大きい．JEITA での自動 生成コードに関する調査では，図 14 に示すように高い 評価結果となっている[10]． 0 -50% -40% -30% -20% -10% 0% 10% 20% 30% 40% 50% 図 14 ソースコード自動生成ツールによる品質向 上率 3.2.2.1. FSM コントローラ FSM コントローラをシステムごと，モジュールごとに 用意するのか，１つで共通化するかは，アーキテクチャ 設計で決定する． FSM コントローラをイベント待ちに して，イベント駆動型アーキテクチャにする．FSM コン トローラを main 関数として，永久ループ構造から各モ ジュールを呼び出すアーキテクチャにする場合もある． FSM コントローラを状態スケジューラ[11]とすることで， 並列状態をシングルコアで実現したり，マルチコアで 実現したりするメカニズムを局所化することができる． FSM コントローラを必要としない場合もある．状態遷移 表モデルでアクションが斜めに配置される場合(図 15①)，アクションはシーケンシャルに実行されることが多 い． この場合，各モジュール間で呼出関係を定義す ることで，FSM コントローラは不要となる(図 15-②)． 7 Copyright CATS 2009 [2009 年 8 月 18 日] CESL モジュール振舞 ■ドライバ データ送信タ スク S 初期 E 待機中 1 2 リセット要求 1 COM_LS I(RST) リセッ ト完了 正 常 2 ⇒待機中 異 常 3 DRV_TX _TSK(R ST) もう１つの方式は，制御系モデルから組込み系モデ ルを呼び出す方式である(図 17)[12]． コントローラモデルは，ECU 上で実行される組込み ソフトウェアとして実現される．コントローラモデルはプ ラントモデルを制御対象として，制御目標を達成する ための制御量を計算する機能である． しかしながら，組込みシステムとしては，故障時の対 応などが要求される．このため，組込みソフトウェアに は，故障を検知し，処理するためのウォッチドッグ監視 機能(図 17-①)に，それを実現するためのタイマや UI 制御のための IO 制御機能(図 17-②)が必要になる．機 能の配置は静的モデルで示し，機能の振舞いは動的 モデルで示す．静的モデルではタスク関連図やコンポ ーネント図など，動的モデルでは状態遷移モデルやア クティビティ図などによって表記される． モジュール構造 ② 送信準備完了待ち Entry: 送信完了待ち Entry: DMA(SET) COM_LSI(TX_SET) Exit: Exit: DMA(CLR) COM_LSI(TX_CLR) 3 4 COM_LSI (RST, TX_SET, TX_CLR) DMA (SET, CLR) //リトラ イ ⇒送信準 備完了待 ち ① データ送信要 求 4 DMA ACK OK 5 ⇒送信完了待ち NG 6 DRV_TX_TSK (TX_REQ) ⇒ DRV_TX_TSK (RST, TX_REQ) 待機中 //リトライ COM OK SndMsg(システム制御タ スク,送信完了) NG 3 DRV_TX_TSK(TX_R EQ) ⇒待機中 SndMsg() //リトライ 図 15 FSM コントローラ不要アーキテクチャ 3.2.3. 組込み系と制御系 組込み系モデルと制御系モデルの依存関係を明 確にする設計方法を定義することで，モデル間の相互 作用を自動的にリポジトリに登録できると考える．では， 組込み系モデルと制御系モデルの依存関係における 設計方法論とはどのようなものであろうか． 組込み系モデルから制御系モデルを呼び出す方 式を図 16 に示す．近年，システムの複雑化に伴い，制 御系モデル内部にある状態遷移モデルが複雑化して いる（図 16-①）． そこで，制御系の状態遷移モデルの大部分を組込 み系モデルに持たせて，制御系モデルが持つ状態遷 移モデルを極力単純化する．制御系モデル内部にあ る状態遷移モデルを外部の組込み系モデルの状態遷 移モデルと融合させる(図 16-②)．当然ながら，制御系 の全ての状態遷移モデルが外部に出せることはない． 組込み系モデルの状態遷移モデルから制御系モ デルを呼び出す構造にする(図 16-③)．こうすることで， システムの変化を組込みモデル側に持たせて，制御 系モデルの複雑化を防止する．4 章で紹介するプラン トテーブル方式がこれに近い方式である． ドライバー W* S E 初期 待機中 1 2 リセット要求 1 COM_LS I(RST) リセッ ト完了 正 常 2 ⇒待機中 異 常 3 DRV_TX _TSK(R ST) 送信準備完了待ち Entry: セットポイント ジェネレータ COM_ LSI(TX _SET) Exit: D MA(CLR) COM_ LSI(TX _CLR) 3 4 R U DMA ACK OK 5 ⇒送信準 備完了待 ち ⇒送信完了待ち NG 6 D RV_TX_T SK ( TX_REQ) ⇒ OK NG SndMsg(システム制御タ スク,送信完了) S2 System Block Model ■ ド ライ バ タ デ ー タ送 信 スク S 初期 待機 中 1 2 ち 送 信準 備 完 了 待 En try : DMA(SET) E リ セ ット 要 求 1 COM_L S I(RST ) リセッ ト完 了 正 常 2 ⇒ 待 機中 異 常 3 ち 送 信完 了 待 En try : COM_LSI( TX_SET) Ex it: Ex it: DMA(CLR) COM_LSI( TX_CLR) 3 4 DRV_T X _TSK( R ST) // リ トラ イ デ ー タ送 信 要 求 DRV_TX_TSK (RST, TX_REQ) DM A AC K 4 OK 5 NG 6 ⇒送 信 準 備完 了 待 ち ち ⇒送 信 完 了 待 DRV_TX_T SK (TX_REQ) ⇒ 待 機中 //リ ト ラ イ CO M OK NG Sn dMs g(シ ス テ ム ス ク, 送 信完 了 ) 3 基準変数またはセットポイント U オープンループ／クローズドループ制御 の出力変数 Y 操作変数 X オープンループ／クローズドループ制御 変数 R 計測値またはフィードバック変数 Z 妨害変数 U オープンループ／クローズドループ制御機能 R U ウォッチドッグ監視機能 ① 故障タイプ 故障処理機能 故障検知機能 ／ 故障診断機能 IO制御機能 S2 E1 タイマ制御機能 ② UI_LSI制御機能 State Transi tion Model 構造モデルや振舞モデルに関する表記法の統一 は，UML によって進められている．しかしながら，多種 多様な問題領域をモデリングするには問領域に特化 した言語が必要として DSL が出現した．このため構造 モ デ ル で は UML 以 外 に ， EAST-ADL ， SysML ， MARTE などが出現した． AUTOSAR では，ハードウ ェア（物理）構造モデルであるトポロジーモデルにソフ トウェア（論理）構造モデルとの関係や，バスに流れる シグナル設計を行い，後工程を支援する ECU コンフィ グレーションツールへ構造モデルのファイル （ARXML)を渡す設計手法を示す(図 18)．しかしなが ら，UML や他の DSL と同様に AUTOSAR は，振舞モ デルと構造モデルに関する相互作用や依存関係つい ては定義していない． 各モデルの依存関係を設計手法により明確化する ことは，はじめは主観的な考えが支配的になる．しかし ながら，実績を重ねていくことで，定量的データが蓄積 され，より客観的な議論ができる． ① ② ドライバーが指定したセットポイント W 図 17 制御系－組込み系 ZIPC DMA (SET, CLR) センサ 意味 W* E2 E2 //リトライ COM_LSI (RST, TX_SET, TX_CLR) R ZIPC S2 State Trans itio n Model DRV_ TX_TSK (TX_R EQ) ⇒待機中 3 X 記号 W S1 E1 待機中 //リトライ COM アクチュエータ プラントモデル 制御対象の システム E1 S1 E2 state transition block Y ROM MPU RAM AD DA UI_LSI ZIPC ZIPC MapleSim S1 4 U ECU W ③ //リトラ イ データ送信要 求 コントローラモデル オープンループ / クローズドループ 制御，監視 R 送信完了待ち Entry: D MA(SET) Exit: Z W ZIPC ■ドライバ データ送信タ スク 環境 制御 タ DRV_TX_T SK(TX_R EQ) ⇒ 待 機中 // リト ラ イ State Transition Model SndMsg() 図 16 組込み系－制御系 8 Copyright CATS 2009 [2009 年 8 月 18 日] CESL 運転タイミング表 構造モデルと振舞モデルの詳細な連携については， 別稿で述べる． ハードウェア構造モデル ソフトウェア構造モデル W ECU R U ROM MPU RA M AD UI _LS I DA W ECU R U ROM MPU RAM AD UI_LSI DA W ECU R U ROM MPU RAM AD UI_LSI DA W U オープ ンループ ／クローズド ループ 制御機能 R U ウォッチド ッグ／監視 機能 故障 検知機能 ／ 故 障診断機能 故障 タイ プ 故障処理機 能 IO制 御機能 タイマ制御機能 UI_L SI制御機能 S1 E1 E1 S1 E2 ■バスに流れるシグナル設計 • 異なるECU上に配置されたSWC間で やり取りされるシグナルのみ バス上に流される • シグナル生成 • シグナルマッピング E1 E2 S2 E3 E2 E3 S1 S2 S2 S2 多重条件表 S2 S2 S3 S3 E1 E1 S1 E2 S3 S3 S3 S1 S3 S1 E3 S1 E1 E2 S2 E3 E2 E3 S1 S1 S2 S2 S2 S2 S2 S3 S3 S3 S3 S3 S1 S3 S1 E3 S1 制御系モデル センサ コントローラ 制御対象 （エンジン, ドライブトレーン） 環境 （外気温, 負荷, 運転者…） トポロジモデル コンポジションモデル E1 E1 S1 E2 E1 E2 S2 E3 E2 E3 S1 S1 S2 S2 S2 S2 S2 S3 E1 E1 S1 E2 S1 S3 E3 後工程（ECUコンフィグレーションツール）へ ファイル（ARXML)を渡す S3 S3 S3 S3 S1 S1 管理表 E1 E2 S2 E3 E2 E3 S1 S1 S2 S2 S2 S2 S2 S3 S3 S3 S3 S3 S1 S3 E3 S1 S1 操作表 図 19 プラントテーブル方式 図 18 AUTOSAR 4.1. 課題 モデルベース開発において，差分開発をする場合 に，可変性をどのように取り扱うかが課題である．C 言 語であれば，#ifdef 文により，ソースコードの一元管理 ができる．また，ソースコード差分検出ツールによって， 差分箇所を表示することもできる．ところが，モデルに おいては，差分そのものはフィーチャモデルで可視化 できるが，フィーチャモデルと他のモデルとの依存関 係は明確にされていない． 本稿では，フィーチャモデ ルと状態遷移モデルに限定して述べる． 4. バリエーションモデルと状態遷移モデ ル 組込みソフトウェアを新規に開発することは少ない． 既存の組込みソフトウェアに追加，変更を加えていく． こうした開発を派生開発，差分開発または流用開発な どと呼ぶ．ソフトウェアプロダクトラインでは共通性・可 変性を分析し，追加，変更される部分と，共通利用さ れるコア資産を蓄積することで，高生産，高品質な開 発を実現する． 国内で初のソフトウェアプロダクトライン殿堂入りを 果たした東芝のプラントテーブル方式(図 19)は，発電 所向け監視制御システムの開発に 30 年以上，国内外 150 以上納入実績を持つソフトウェアプラットフォーム 構築技術である[13,14]．制御系モデルをコア資産化し， 可変性の高い部分をテーブルにすることで高生産，高 品質な開発を実現する．テーブルは１プラントあたり 2000 枚から 5000 枚程度だという． 4.2. 解決方法 状態遷移モデルに C 言語と同様に#ifdef 文を採用 する．状態遷移モデルの事象，状態，そしてアクション に#ifdef 文を記述することで，バリエーションに応じた 振舞いを行う状態モデルを確定できる．バリエーショモ デルと状態遷移モデルにおける相互作用を図 20 に示 す． プロダクトのバリエーションをフィーチャモデルで指 定し，指定された状態遷移モデルを確定する(図 20-①， ②)．遷移先や処理の変更はアクションセルに#ifdef 文 で記述する(図 20-③)． 状態遷移モデルに可変性が存在し，状態遷移モデ ルから呼び出されるモジュールに共通性が存在すると 仮定した場合，状態遷移モデルが図 19 で示したプラ ントテーブルに相当し，アクション・アクティビティが制 御系モデルに相当する． 9 Copyright CATS 2009 [2009 年 8 月 18 日] CESL プロダクト1 プロダクト2 Root V1 V1_1 F1 V1_2 F2 O1 V1 V1_1 F3 F1 V1_2 F2 入力 (F1, F3) [1] S1 S2 入力 (F2, F3) S3 E1 E2 =>S3 E3 F3 =>S1 #endif ② ① [2] #endif S1 S1 E3 F3 #ifdef F2 #ifdef F3 ③ #ifdef F1 …. #elif F2 =>S2 #elif F3 =>S3 #endif E1 参考文献 Root O1 S3 COM_LSI (RST, T X_SET, TX_C LR) S3 S1 E1 DMA (SET , CLR) E2 DRV_TX_TSK (RST, TX_REQ) E3 S2 S3 S2 [3] S3 S1 SndMsg() 図 20 バリエーションモデルと状態遷移モデル [4] 実際の車載オーディオにおける状態遷移モデルの 差分箇所を調査したものが表 1 である[15]．オリジナル モデルから変更された個所が可変性個所であり，バリ エーションとなる．11 枚の状態遷移表モデルから構成 される状態遷移表モデルのどの部分に差分が起こる かを調査した結果，事象の変更が 1 か所，状態の変更 が 1 か所，アクションの変更が 104 か所であった． この結果から，状態遷移モデルのバリエーションは， 事象と状態よりは，アクションに多く発生することが分 かった． バリエーションモデルと振舞いモデルの詳細な連携 については，別稿で述べる． [5] [6] [7] [8] [9] 表 1 車載オーディオ状態遷移表差分 original stm no E S 1 4 26 2 8 17 3 2 3 4 15 37 5 3 32 6 10 27 7 11 20 8 12 9 9 13 12 10 11 19 11 3 8 total 92 210 A 104 136 6 555 96 270 220 108 156 209 24 1884 update total E S 134 4 26 161 8 17 11 2 3 607 15 37 131 3 33 307 10 27 251 11 20 129 12 9 181 13 12 239 11 19 35 3 8 2186 92 211 diff A total E S A 104 134 0 0 3 136 161 0 0 6 6 11 0 0 0 555 607 0 0 31 99 135 0 1 8 270 307 0 0 41 220 251 0 0 9 108 129 0 0 0 156 181 0 0 0 209 239 1 0 6 24 35 0 0 0 1887 2190 1 1 104 [10] [11] [12] 5. むすび モデリング表記法は，UML vs. DSL となり，SysML, MARTE, EAST-ADL, AUTOSAR, TECS など数多くの モデリング表記法が生み出されている．このような状況 で統合化モデルの重要性は高まるばかりではある． このため，斬新で，萌芽的なアイディアを地道に実 践し，その結果のデータを収集，分析することで 定量 化することが重要である． [13] [14] 10 経済産業省商務情報政策局情報処理振興課長 八尋俊英，組込みソフトウェア産業の課題と政策 展開，2008 年 11 月 19 日 http://imyme.chicappa.jp/ET2008/conference/ima ge/ET2008_S-2.pdf 玉井哲雄，ソフトウェア工学の基礎，岩波書店， 2004. 村松鋭一，山形大学工学部制御工学 テキスト， http://www13.plala.or.jp/control/control1/c1_chap ter1.pdf Roger S. Pressman 著，飯塚悦功・西康晴監訳， ソ フ ト ウ ェ ア 工 学 の 伝 統 的 手 法 ，日 科 技 連 ， 2000. AUTOSAR: http://www.autosar.org/ MOF QVT Final Adopted Specification ，2007， http://www.omg.org/docs/ptc/05-11-01.pdf Capers Jones, Assessment and Control of Software Risks, Yourdon Press, 1994 経済産業省:平成 19 年 2008 年版組込みソフト ウェア産業実態調査＜プロジェクト責任者向け ＞ 小柴 豊， ＠IT 読者調査結果：情報マネージャ ／IT アーキテクト編（2）～モデリングの現状と課 題とは？～，アットマーク・アイティ，2005/2/26， http://www.atmarkit.co.jp/news/survey/2005/02ar cmng/arcmng.html 社団法人 電子情報技術産業協会 ソフトウェア 事業員会，平成 19 年度 ソフトウェアに関する調 査報告書Ⅱ 組込み系ソフトウェア開発の課題 分析と提言 ～大規模化，複雑化，短納期化， 他機種化の波にどのように立ち向かうべきか～， 2008． 渡 辺 政 彦，拡張階層化状態遷移表設計手法 Ver.2.0，東銀座出版社，1998． ヨーク・ショイフェレ，トーマス・ツラフカ共著，福 田晃監修，オートモーティブソフトウェアエンジニ アリング～原則，プロセス，手法，ツール～，日 刊工業新聞社，2008 年 10 月 滝沢治，赤石富士雄，早瀬健夫，ソフトウェアプ ラットフォーム構築技術，東芝レビューVol.64， No.4，2009． 中本泰発，河原春郎，前大道正博，小暮洋一郎， 阿部正夫，50 年形発電所計算機制御システム Copyright CATS 2009 [2009 年 8 月 18 日] CESL 「COPOS」の開発，東芝レビューVol.29，No.10， 1974． [15] 渡辺政彦，福田 晃，中西 恒夫，細谷伊知郎， 城戸滋之，“状態遷移表差分抽出技術とツール の 提 案 と 評価，”組込みシステムシンポジウム 2008(ESS1008) 論 文 集 ，pp.79-87 ，2008 年 10 月． 渡辺政彦 1984 年日本大学・文理学・英文科卒． 2009 年九州大学大学院システム情 報科学府博士後期課程修了． 博士（工学）．情報処理学会会員．電 子情報通信学会会員． 現在，キャッツ株式会社取締役副社長 兼 最高技術 責任者 兼 キャッツ組込みソフトウェア研究所所長， 九州工業大学大学院情報工学研究院客員教授． 11 Copyright CATS 2009 [2009 年 8 月 18 日]