南山大学 数理情報学部 情報通信学科 2007 年度卒業論文要旨集

車載ネットワークのフレームワーク設計方法の提案
2004MT008 江口 悠樹

2004MT064 水谷 拓人

指導教員 青山 幹雄

1. はじめにソフトウェア開発において，汎用機能を提供するものとしてフレームワークが利用されている．しかし，開発者がフレームワークを設計する際に，規模の増大による設計の複雑さが問題とされている．本研究では，この問題を解決するフレームワークの設計方法を提案する．

2. フレームワーク設計の問題と解決策
2.1. フレームワークとはフレームワークとは，開発者がカスタマイズできるアプリケーションの骨組みである[1]．フレームワークの中でカスタマイズ可能な部分をホットスポットと呼ぶ．また，今後の変更が起こらないと思われる部分をフローズンスポットと呼ぶ．
2.2. フレームワーク設計の問題点と解決策
フレームワークを設計する際，フレームワーク規模の増大による複雑さが問題とされている．この問題を解決するために本研究では，フレームレットとデザインパターンを用いた設計方法を提案する．

3. 提案する設計方法
3.1. フレームレット分割
フレームレットとは，フレームワークの機能を複数のまとまりのある機能に分割したものである．フレームワーク規模の増大問題を解決するため，フレームワークを複数のフレームレットに分割して設計する．各フレームレットは互いに疎結合であるため，それぞれ設計解を導き，その後統合するプロセスをとることが可能である．
3.2. デザインパターンの適用
デザインパターンとは，ソフトウェア開発において繰り返し現れる設計課題とその解決方法を整理したものである[2]．
例として，ステートパターンを説明する．ステートパターンとは，複数の状態を持つプログラムを作成する際，「状態」をクラスで表現するデザインパターンである．そして Context
インタフェースを状態管理するクラスとして置いている．

4. CAN フレームワーク設計への適用
4.1. CAN とはCAN(Controller Area Network)とは，車載ネットワークの標準通信プロトコルである[3]．CAN プロトコルは OSI 参照

モデルのデータリンク層と物理層を規定している．通常，CAN のプロトコルは CAN コントローラというハードウェアで実装されている．
4.2. CAN フレームワークの設計プロセス
CAN フレームワークの設計に提案設計方法を適用する．
図 1 に設計プロセスを示す．提案設計方法が反映されている部分は，「フレームワーク概念定義」フェーズでフレームレットに分割する部分．そして，「フレームレット概念定義」フ
ェーズで各フレームレットのホットスポットを特定し，ステートパターンを適用してクラス図で表現する部分である．その後，フレームレットを統合する設計を「フレームレットアーキテクチャ設計」で考え，統合を行う．

研究対象範囲フレームレットに分割

ドメイン分析

・フレームレットごとにホットスポットの特定・ステートパターンの適用

CANフレームワーク概念定義
分割

CAN_TXフレームレット
概念定義

CAN_RXフレームレット
概念定義

CAN_TXフレームレット
アーキテクチャ設計

CAN_RXフレームレット
アーキテクチャ設計

分割したフレームレットを統合する構造を設計

統合
フレームレットの統合

図 1 CAN フレームワークの設計プロセス
4.3. CAN フレームワーク設計における前提条件
図2 は CAN コントローラの構成と送受信処理の動作を示す．CAN フレームワークの対象を CAN コントローラ中のCAN core とし，設計する上で次の前提条件を設定する．
(1) フレームワークの適用範囲を，CAN core と CAN バス
間のフレーム送受信処理に限定(2) 本研究で扱う設計問題は図2のCAN coreに含まれる
7 つのユニットのうち CAN_RX，CAN_TX に限定(3) 他 5 つのユニットから提供される同期機能やフレーム作成機能は利用できるものとする(4) 設計プロセスの「ドメイン分析」から「フレームレット概念定義」までを対象とする

南山大学 数理情報学部 情報通信学科 2007 年度卒業論文要旨集
CANコントローラ
CAN coreインタフェース

従って，7 つのユニットをフレームレット分割の基準とする．
各フレーム名と機能を表 2 に示す．

フレーム送信処理

CANcore
研究対象

受信データ

CA
N

受信
フレーム

CAN_RX

バス

上位プロトコルの処理

送信
フレーム

CAN_TX

送信データ
Synchronizer

CRC_CALC

Error_counter

Stuff Handler

フレーム受信処理

Error Frame Generator

図 2 CAN コントローラの構成と処理
4.4. ドメイン分析
対象ドメインは，CAN バスに対して CAN core が行う処理である．前節の前提条件(2)より，設計対象はフレーム受信処理を行うCAN_RXとフレーム送信処理を行うCAN_TXである．また CAN_RX と CAN_TX は標準フレーム規格と拡張フレーム規格で，処理の違いを考慮する必要がある．
標準，拡張フレーム規格を考慮した4種類のフレームを図3に示し，各フレームの説明を表 1 に示す．リモートフレームのフィールド構成はデータフィールドの有無以外，データフレームと同じである．
リモートフレーム
SOF アービトレーション

コントロールCRC ACK EOF

データフレーム
SOF アービトレーション

コントロール

データID(11bits)

RTR IDEr0ID(11bits)

SRR IDEID(18bits)

CRC ACK EOF

DLC0～3 （標準フレーム）
RTR IDEr1
r0 DLC0～3（拡張フレーム）

エラーフレーム
エラーフラグ

エラーフラグの重ね合わせ

フレームレット名
Synchronizer
CRC_CALC
Error Frame
Generator
Stuff Handler
Error_counter
CAN_TXCAN_RX機能
CAN コントローラを同期伝送誤りがないか判断
エラーフレームを作成
周期的に再同期をさせる
エラーカウントし一定数以上でバスオフ
フレーム送信処理
フレーム受信処理

4.6. CAN_RX フレームレット概念定義
4.6.1. CAN_RX フレームレットのホットスポット特定
CAN コントローラがフレームを受信する状態遷移を図 4に示す．CAN プロトコルの規格の違いによる CAN_RX，CAN_TX の処理を考慮している．図 4 より，同期してからCTRL でデータ長を測る処理は標準，拡張フレーム規格で異なる．従ってここをホットスポットとし，IDLE から EOF までを RX ホットスポット部分と呼ぶことにする．
RX ホットスポット部分に対し，オーバーロードフレームのフィールド構成は 1 つである．従って，処理は共通となるのでフローズンスポットとなる．Intermission から End ofIntermission を RX フローズンスポット部分と呼ぶことにする．

エラーデリミタ

RXフローズンスポット部分

RXホットスポット部分

オーバーロードフレーム
オーバーロードフラグ

表 2 分割したフレームレットとその機能

オーバーロードフラグのオーバロードデリミタ
重ね合わせIDLE

図 3 4 種類のフレームと各フィールド構成

ホットスポット

表 1 フレーム名と説明
フレーム名
データフレーム
リモートフレーム
エラーフレーム
オーバーロードフレーム

説明
データ送信
受信側が送信要求
エラー通知
受信準備未完了を通知

受信待機

受信可能状態,バス開放状態

対応
TX
TX
TX
RX

表1 に示すように，CAN_RX，CAN_TX で扱うフレームは決まっている．CAN_RX が扱うフレームは，受信未完了を伝えるオーバーロードフレーム．CAN_TX が扱うフレーム
は，フレーム送信するCANコントローラ側のCAN_TXが送信するデータフレームとエラーフレーム．そして，フレーム受信する CAN コントローラ側の CAN_TX が送信するリモートフレームである．
4.5. フレームワーク概念定義
4.5.1. フレームレット分割
CAN core に含まれる 7 つのユニット同士は独立している．

SYNC

拡張フレーム受信標準フレーム受信

Extended frameStandard frame
コントロールフィールドコントロール
フィールド
（拡張）
CTRL_EXT

End ofIntermissionOverLoad
Frame

遅延終了

送信可能状態Intermission
オーバーロードフレーム
フレーム
送信完了
受信完了
EOF

CTRL

ACK
リモートフレーム
or
処理完了
データフレームにデータなし

データフレーム
and
データあり
DATA_RCVDATA_RCV
処理完了

CRC

CRC
処理完了

ACK
リモートフレーム
データフレーム

図 4 フレーム受信側の状態遷移図
4.6.2. CAN_RX 処理にステートパターン適用
RX ホットスポット部分は標準フレーム規格と拡張フレー
ム規格の処理を 2 つの「状態」に分けて処理するため，ステートパターンを適用する．そして，RX フローズンスポット部分はオーバーロードへの遷移があるかないかを 2 つの「状態」に分けて処理するためステートパターンを適用する．

南山大学 数理情報学部 情報通信学科 2007 年度卒業論文要旨集
RXホットスポット部分とRXフローズンスポット部分にステートパターンを適用したクラス図を図 5 に示す．
1)
RX ホットスポット部分の設計
状態管理をさせるために Rx_Context インタフェースを置
き，実装をRx_Frameクラスで行う．doIDfilterメソッドで，フレームの ID から受信するフレーム規格を判断する．判断結果から，changeState メソッドで各規格の処理へ遷移する．
状態を表す抽象クラスとして Rx_Frame_State インタフェースを置く．状態を実装する具象クラスがRx_Standard_State クラスと Rx_Extended_State クラスである．
具象クラス内の各メソッドが処理を実装する．
2)
RX フローズンスポット部分の設計
Rx_Context インタフェースは状態管理を行うインタフェー
スを示し，Rx_Frame クラスで実装を行う．doIntermission は休止状態の管理を行うメソッドである．
Overload_State は，オーバーロードへの状態遷移を示している．doTrans_Overloadは，オーバーロードフレームを送信処理するメソッドである．

<<interface>>
Rx_Context<<interface>>
Rx_Frame_State

doIDfilter
changeState

doCTL
doData_Rcv
doCRC
doACK
doEOF

<<interface>>
Rx_Context
doIntermissionchangeState

Rx_Frame- Rx_Frame_State
doIDfilter
changeState

RXホットスポット部分

doCTL
doData_Rcv
doCRC
doACK
doEOF

Rx_Frame- Overload_state

OverLoad_State

doIntermisisonchangeState

doTrans_Overload
RXフローズンスポット部分

図 5 RX ホットスポット部分とフローズンスポット部分<<interface>>
Overload_State

doIDfilter
doIntermission
changeState

Rx_Frame-Overload_State-Rx_Frame_State
doIDfilter
doIntermisisonchangeState

Rx_Standard_State

Rx_Extended_State

図 6 CAN_RX フレームレット
4.7. CAN_TX フレームレット概念定義
4.7.1. CAN_TX フレームレットのホットスポット特定
CANコントローラが送信状態の状態遷移を図7に示す．
SOF から TRANSMITTING へ状態遷移する際に，データ，リモートフレームの作成が行われる．標準フレーム規格と拡張フレーム規格で作成されるフレームではビット数が異なるので，フレーム作成処理が異なる．従って，ここをホットスポットとし，SOF から TRANSMITTING を TX ホットスポット部分と呼ぶことにする．
エラー通知を受けた場合，エラーフレームの作成を行い
TX_ERROR からエラーフレームの送信を行う．エラーフレー ム の フ ィ ー ル ド 構成を フ ロ ー ズ ン ス ポ ッ ト と し ，TRANSMITTING から TX_ERROR を TX フローズンスポッ
ト部分と呼ぶことにする．なお，エラーフレーム作成を行うのは Error Frame Generator フレームレットである．
送信完了,
エラーアクティブ状態

OFF

バス開放状態,フレーム作成開始,バス待機状態

エラー解消
エラーフレーム送信完了,バスオフ状態

TXホットスポット部分
SOF
フレーム作成完了

TRANSMITTING

フレーム作成開始

SUSPEN

エラー
通知

送信完了,エラーパッシブ状態

エラーフレーム送信完了,エラーパッシブ状態

TX_ERROR

4.6.3. CAN_RX フレームレット図5 の 2 つのクラス図は，図4 の状態遷移図からステートパターンを用いて別々のクラス図で表現している．従って，CAN_RX フレームレットは図 5 のクラス図を組み合わせて表現できる．CAN_RX フレームレットのクラス図を図 6 に示す．各クラス間の関係は次のようである．
状態管理を行う Rx_Context インタフェースの実装をRx_Frame クラスが行う．ホットスポット部分を抽象クラス
Rx_Frame_State と 具 象 ク ラ ス Rx_Standard_State ，
Rx_Extended_State で表現する．フローズンスポット部分をOverload_State クラスで表現する．

<<interface>>
Rx_Frame_State

Overload_State

doTrans_Overload

Rx_Standard_State Rx_Extended_State
doCTL
doData_Rcv
doCRC
doACK
doEOF

<<interface>>
Overload_State<<interface>>
Rx_Context

TXフローズンスポット部分

図 7 フレーム送信側の状態遷移図
4.7.2. CAN_TX 処理にステートパターン適用
CAN_RX と同様の理由から，TX ホットスポット部分と TXフローズンスポット部分にステートパターンを適用した．クラス図を図 8 に示す．
1)
TX ホットスポット部分の設計
状態管理をする Tx_Context インタフェースを置き，実装を Tx_Frame クラスで行う．doSOF は送信開始の処理を行うメソッドであり，doOFF はユニットを終了するためのメソッドである．また，doSUSPEN は送信の一時停止を行うメソッドである．
メッセージの送信処理をする Tx_Frame_State インタフェースを置いた．そして，標準フレーム規格と拡張フレーム規南山大学 数理情報学部 情報通信学科 2007 年度卒業論文要旨集
格の処理を 2 つの「状態」として処理するために，具象クラス Tx_Standard_State クラスと Tx_Extended_State クラスで実装した． CAN の送信でアービトレーションを行うため，
doArbitration メソッドでアービトレーション機能を提供する．
doTRANSMITTING メソッドでメッセージのフレーム化やフレーム送信を行う機能を提供する．
2)
TX フローズンスポット部分の設計
E_Freme_State インタフェースはエラーフレームを送信する状態を示すクラスであり，具象クラス Error_State で実装する．doError_TRANS メソッドはエラーメッセージ送信を行う．
<<interface>>
Tx_Context
doSOF
doOFF
doSUPENchangeState<<interface>>
Tx_Frame_State<<interface>>
Tx_Context

doArbitration
doTRANSMITTING

doOFF
doSUPENchangeState<<interface>>
E_Frame_State
doError_TRANS

Tx_Frame-Tx_Frame_State
doSOF
doOFF
doSUPENchangeState

Tx_Frame-E_Frame_State

Tx_Standard_State

Tx_Extended_State

doArbitration
doTRANSMITTING

doOFF
doSUPEN
doArbitration
doTRANSMITTING changeState

TXホットスポット部分

Error_State
doError_TRANS

TXフローズンスポット部分

図 8 TX ホットスポット部分とフローズンスポット部分
4.7.3. CAN_TX フレームレット
CAN_RX フレームレットと同様，CAN_TX も状態管理にTx_Context インタフェースを置いている．従って図 8 のクラスを組み合わせることが可能である．TX フレームレットのクラス図を図 9 に示す．各クラス間の関係は次のようである．
状態管理を行う Tx_Context インタフェースの実装を
Tx_Frame ク ラ ス が 行 う ． ホ ッ ト ス ポ ッ ト 部 分 は
Tx_Frame_State インタフェースを置き，Tx_Standard_State とTx_Extended_State が実装する．フローズンスポット部分は，
E_Frame_State インタフェースを Error_State が実装する．
<<interface>>
Tx_Context
doSOF
doOFF
doSUPENchangeState<<interface>>
E_Frame_State

Error_State<<interface>>
Tx_Frame_State

Tx_Frame-E_Frame_State

規格の状態遷移の違いをホットスポットとした．CAN_RX，CAN_TX 共に異なる規格をホットスポットにすることでホットスポット部分を変更が可能であり，適切といえる．また，標準と拡張フレームの規格に応じて実装でき，ホットスポット部分の実装を変更することで CAN_RX，CAN_TX のフレームレットを再利用可能である．
(2) フレームレットのフローズンスポットの評価
ホットスポットと別の状態のクラスで表すことでフローズンスポットの振る舞いがホットスポットより分離される．ホットスポットが変更されてもフローズンスポット部分の実装は影響されない．

6. 考察(1) フレームレット分割
CAN フレームワークの設計にフレームレット分割を取り入れたことでまとまりのある複数の機能に分割することができた．
(2) ホットスポット，フローズンスポットの特定
ホットスポットを特定することによって変更，追加が可能な部分が特定できる．従って，柔軟なフレームレットが設計できる．また，フローズンスポットを特定することで今後変更されないと考えられる部分の特定ができる．従って，フレームレットの変更されない部分が明確にして設計できる．

7. 今後の課題
CAN_RX，CAN_TX フレームレットのクラス図から実装できるかどうか検証する必要がある．また，CAN_TX，CAN_RX フレームレット以外の 5 つのフレームレットを設計し，設計後に統合する必要がある．

8. まとめ本研究では，フレームワークの規模増大による設計の複雑さを問題とした．解決方法として，フレームレットとデザインパターンを利用した設計方法を提案した．提案方法を用いて，CAN フレームワーク設計を行った．評価では，提案設計方法の妥当性を確認した．

-Tx_Frame_State

doSOF
doOFF
doSUPENchangeState

Tx_Standard_State

Tx_Extended_State

参考文献
[1]

図 9 CAN_TX フレームレット[2]

5. フレームレット評価
フレームレットの評価基準として，ホットスポットを変更してフレームレットが再利用できるか，またフローズンスポットが変更されない部分として適切かについて評価する．
(1) フレームレットのホットスポットの評価
CAN_RX，CAN_TX 共に標準フレームと拡張フレーム

[3]
[4]

R． Johnson ほか，パターンとフレームワーク，共立出
版，1999．
A．Pasetti，Software Frameworks and EmbeddedControl Systems，Springer，2002 [佐藤 啓太, 宇佐美
雅紀 ( 訳 ) ， フ レ ー ム レ ッ ト ， 翔泳社， 2 0 0 5 ] ．
佐藤 道夫，車載ネットワーク・システム，CQ 出版社，
2005．
Q．Zhao，Integrated CAN Controller Design for theImsys IM 31XX Microcontroller，http://web.it.kth.se/~srs/MSc_theses/Qiang_Zhao_MSc-thesis.pdf．