BridgePoint 版

鹿威し

解説書

FirstRelease Apr12 2004
V1.0（株）リコー

斎藤 賢一

目次

1

はじめに ______________________________________________________________ 3

2

MDA 概要_____________________________________________________________ 3

3

開発プロセス概要 _______________________________________________________ 44要求仕様 ______________________________________________________________ 5

5

モデル解説 ____________________________________________________________ 6
5.1

ユースケース _______________________________________________________ 6

5.1.1 ユースケース図____________________________________________________________ 6
5.1.2 ユースケース記述__________________________________________________________ 6
5.2

ドメインとブリッジ__________________________________________________ 8

5.2.3 ドメインチャート__________________________________________________________ 8
5.2.4 ドメイン記述とブリッジ記述________________________________________________ 8
5.3

クラス ____________________________________________________________ 9

5.3.5 クラス図__________________________________________________________________ 9
5.3.6 クラス説明________________________________________________________________ 9
5.3.7 関連の説明_______________________________________________________________ 10

6

5.4

ステートマシン図とアクション記述 ____________________________________ 12

5.5

コラボレーション図_________________________________________________ 13

5.6

同期サービス ______________________________________________________ 14

モデルコンパイラによる自動コード生成 ____________________________________ 16
6.1

コード生成概略 ____________________________________________________ 16

6.2

色づけ概要________________________________________________________ 16

6.3

コード生成________________________________________________________ 17

6.3.1 環境設定_________________________________________________________________ 17
6.3.2 システムノードの作成_____________________________________________________ 17
6.3.3 OO ドメインフォルダの作成________________________________________________ 17
6.3.4 フォルダ構成_____________________________________________________________ 18
6.3.5 色づけ___________________________________________________________________ 18−1−6.3.6 コード生成_______________________________________________________________ 22
7

設計指針 _____________________________________________________________ 24
7.1

モデルコンパイラの設計指針__________________________________________ 24

7.2

モデルコンパイラのカスタマイズ ______________________________________ 24

7.3

タスク相関図 ______________________________________________________ 24

8

手書きコードとモデルとのインタフェース___________________________________ 25

9実装環境 _____________________________________________________________ 26
9.1

ビルド ___________________________________________________________ 26

9.2

デバッグ _________________________________________________________ 28

9.3

ROM 化 __________________________________________________________ 29

9.4

実行 _____________________________________________________________ 29

−2−

はじめに

1

近年、組み込みソフトウェアの業界において、UML を用いたオブジェクト指向手法は急速に広まり、また、最近では MDA （Model Driven Architecture：モデル駆動型アーキテクチャ）技術を用いた開発手法も実用段階に入り、組み込みソフトウェアの開発手法が変わりつつある。
このような背景から、SESSAME（組込みソフトウェア管理者・技術者育成研究会 ）で紹介された

鹿威し（ししおどし） の仕様（（株）東陽テクニカ 二上氏作 「セサミ電気

Sozex002

ソフ

トウェア仕様書 v1.2」）をもとに、TOPPERS/JSP カーネルを利用し、かつ、MDA 技術を用いて威し

鹿の開発を行ってみた。

MDA 技術には組み込み業界で実績のある Executable UML の概念を適用し、CASE ツールには

BridgePoint 6.1D（Project Technology 社）を使用した。また、モデルをコードに変換するツールとして、同じ Project Technology 社のモデルコンパイラ（MC-3020 v3.3）を使用した。
実機環境としては、オークス電子（株）の OAKS16-MINI キットのボードを使用し、統合開発環境として、キットに付属の TM V.3 を使用した。
TOPPERS/JSP カーネルは jsp-1.4 を使用した。

2

MDA 概要MDA は UML によるモデルベースのオブジェクト指向開発をさらに進化させる、モデリング

主導のシステム開発、およびライフサイクル管理を実現するための参照アーキテクチャである。
「駆動」という言葉には「まずモデルありき、モデルが定義されることで特定言語や製品へのマッピングは自動的に決定し、さらにシステム管理、インテグレーションもモデルを中心として行うことを可能にする」という意味が込められている。
MDA は対象となるアプリケーションの機能要求による仕様と実装技術（プログラミング言語,OS,ミドルウェアなどのプラットフォーム）を分離して開発する方法を提供する。モデルを各種のプラットフォーム技術へとマッピングすることによって、プラットフォーム技術の変化に対応することのできる堅牢なフレームワークを提供する。仕様と実装技術を分離することによって、高度な自動化を可能にし、従来に比べて高い生産性を実現する。
MDA では、プラットフォームに対して、実装技術（プラットフォーム）に依存しないモデルと依存するモデルを定義する。
・ PIM（Platform Independent Model）＝プラットフォーム独立モデル：実装技術非依存
・ PSM(Platform Specific Model)＝プラットフォーム固有モデル：実装技術依存
PIM はシステムの本質（機能要求）を表す分析モデルであり、PSM は実装技術の情報が付加された設計モデルである。
MDA によるシステム開発は、機能要求による仕様を表現する分析モデル(PIM)を作成し、非機能要求を考慮した設計モデル(PSM)へ変換（マッピング）した後コードを生成する。

−3−

開発プロセス概要

3

Executable UML の開発プロセスから実装、ROM 化までのプロセスを以下に示す。

分析
制御、機能

情報

要求分析

シ
ス
テ
ム
要
件

テ
ク
ニ
カ
ル
ノ
¦
ト

ソ
フ
ト
ウ
ェ
ア
要
求
仕
様
書

機
能
要
件
ユ
¦
ス
ケ
¦
ス
分
析

ド
メ
イ
ン
分
割

ク
ラ
ス
図

実装

状
態
図

コ
ラ
ボ
レ
¦
シ
ョ
ン
図

コ
¦
ド
生
成

設計
非
機
能
要
件

図 3.1

ア
¦
キ
テ
ク
チ
ャ
定
義
書

モ
デ
ル
コ
ン
パ
イ
ラ
選
定

ア
ク
シ
ョ
ン
記
述

T
O
P
P
E
R
S
カ
¦
ネ
ル

モ
デ
ル
コ
ン
パ
イ
ラ
の
カ
ス
タ
マ
イ
ズ

コ
ン
パ
イ
ル

リ
ン
ク

R
O
M
化

デ
バ
イ
ス
制
御
コ
¦
ド

開発プロセス概要図

各フェーズの解説
要求分析フェーズ
要求分析フェーズでは、システム要件を基に技術調査や要求の整理を行う。機能要求はユース
ケース図とユースケース記述でまとめ、非機能要件は、別途記述を行う。要求を基にシステムを問題領域毎に分割したドメインチャートを作成し、以降、ドメイン毎に並行作業を行う。
分析フェーズドメイン単位にクラスを抽出し、クラス図を作成する。クラスには振る舞いを持つものと持たないものがあり、振る舞いを持つクラスは状態図を作成する。また、各状態で行うべきプロセス−4−

をアクション言語で記述する。
状態を持つクラスにおけるクラス間のイベントのやり取りをコラボレーション図で表現する。
アクションまで記述すれば、モデルの段階でシミュレーションが可能であり、実装に依存しないモデルを論理検証することができる。
設計フェーズ
非機能要件を実現するための設計戦略を記述したアーキテクチャ定義書を作成する。また、システム要件に最適なモデルコンパイラの選定を行い、必要であればモデルコンパイラのカスタマイズを行う。また、タイマーなどのメカニズムライブラリを用意しておく。
実装フェーズ
デバイス制御用コードを用意しておく。モデルコンパイラによりコード生成を行い、他のソースと一緒にコンパイル、リンクを行う。実行ファイルができたら ROM へ書き込み、動作検証を
行う。

4

要求仕様
冒頭でも述べたように、ソフトウェア仕様書として、・ （株）東陽テクニカ

二上氏作「セサミ電気Sozex002 ソフトウェア仕様書 v1.2」

二上氏作「セサミ電気鹿威し

また、企画書として、・ （株）東陽テクニカ

を基にした。

−5−

開発企画書 v4.1」

5

モデル解説
5.1

ユースケース

ソフトウェア要求仕様書から、アクターを抽出し、アクターに価値を与えるシステム要件をユースケースとして抽出した。
5.1.1 ユースケース図

図 4.1

ユースケース図5.1.2 ユースケース記述
UC-01：鹿威しを開始する
概要
システムが始動し、鹿威しが開始される。
アクター
亭主
事前条件
なし
事後条件
定期的にコーン音響が響いている。
基本系列
1. アクターは、システム開始を要求する。
2. システムは、ポンプを作動させ、竹に水をためる。
3. システムは、竹に水が満水になり、竹が離床し、反転したことを知る。
4. システムは、水はねを防止するため、ポンプを一時停止させる。
5. アクターは、コーン音響を楽しむ。
−6−

5. システムは、竹の水が空になり、竹が着床し、反転したことを知る。
6. 2 から 5 を繰り返す。
代替系列
3.1

水をため始めてから 80 秒間離床しなければ異常と判断し、LED ランプを点滅させる。

5.1

離床してから 20 秒間着床しなければ異常と判断し、LED ランプを点滅させる。

6.1

システムを開始してから 180 分間何も操作がなければ、消し忘れのためにシステムを停

止する。
備考
なし
UC-02：鹿威しを停止する
概要
システムが停止する。
アクター
亭主
事前条件
システムが開始されている。
事後条件
システムが停止している。
基本系列
1. アクターは、システム停止を要求する。
2. システムは、竹に水が満水になり、竹が反転したことを知る。
3. システムは、竹筒に残っている水をすべて吐き出した後、ポンプを停止させる。
代替系列
なし
備考
なし
VMUC-02：保守する
概要
T.B.D

−7−

5.2

ドメインとブリッジ

5.2.3 ドメインチャート

鹿威し<<realized>>
デバイス制御<<realized>>IR<<realized>>
portModel Compiler<<realized>>
ITRON
図 4.2

<<realized>>C

ドメインチャート

5.2.4 ドメイン記述とブリッジ記述
ドメインの使命鹿威し domain
水流を制御し、快適なコーン音響をユーザーに提供する。
デバイス制御 domain
スイッチ、ランプ、リモコンセンサ（IR）を制御する手段を提供する。
Model Compiler domain
C 言語によるコンパクトな設計思想を反映した、変換による実装を提供する。
ブリッジ記述鹿威し? ?

デバイス制御・鹿威しドメインは、デバイスに情報を伝えるためにもしくは、デバイスの情報を伝えてもらうためにデバイス制御ドメインを使う。
鹿威し? ? Model Compiler、UI? ? Model Compiler
鹿威しドメイン、UI ドメインは、システムの設計思想を利用するために Model Compiler ドメ
インを使う。

−8−

5.3

クラス

5.3.5 クラス図
ししおどしドメインのクラス図を以下に示す。

図 4.3

クラス図

5.3.6 クラス説明
各クラスに関する解説を行う。解説の表で使われている記号、略語を以下に示す。
* ------------- インスタンスを特定することができる属性（識別子）
UL ---------- ユーザー定義型（6.3.5 章のデータ型の指定参照）
竹筒 ( S _ B )竹筒そのもの表したクラス。

*

属性

型

記述

position

integer

竹筒がどこにあるかをあらわす属性。竹筒が複数あった
場合でも、この属性で特定することができる。

pondage_timeout

UL

水が貯まりだしてから離床するまでの最大時間。この時間を超えると異常と判断する。単位：µsec

discharge_timeout

UL

水がなくなってから着床するまでの最大時間。この時間を超えると異常と判断する。単位：µsec−9−

timer_id

inst_refpomp_noタイマーをスタートさせたときのハンドル

R3 （参照属性） (ポンプ.pomp_no と同様)

ポンプ ( S _ P )給水ポンプを抽象化したクラス。

*

属性

型

記述

pomp_nointeger

ポンプを特定する属性。ポンプが複数あった場合にこの属性で特定できる。

restartboolean

再給水されたことを示す
TRUE：再スタート開始
FALSE：再スタート開始しない

wait_time

R4 （参照属性） (運転.wait_time と同様)

叩き石 ( S _ S )竹筒の土台となる石。竹筒がこの石から離れ、戻ってきたときにコーン音響が発生する。

*

属性

型

記述

stone_nointeger

叩き石を特定する値。

position

R2 （参照属性） (竹筒.position と同様)

corn_position R1 （参照属性） (竹筒.position と同様)
運転 ( S _ D )鹿威しの運転に関する責務を持つ。

*

属性

型

記述

wait_time

UL

停止指示から、一定時間遅らせて停止させるための TIME 値。

running_timeout

integer

消し忘れ防止の為の最大運転時間、すなわち操作しない時間を表す。単位：分

status

運転の状態を表す。
boolean TRUE：ON
FALSE：OFFcurrent_countinteger 操作しない時間がどれだけ続いているかを表す。単位：分interval_time

ULrunning_timer_id

inst_ref タイマーをスタートさせたときのハンドル

180 分をカウントするためのインターバルタイム。
今回は 60 秒とする。

5.3.7 関連の説明
R1 : 竹筒 ( 1 : 1 ) 叩き石
１つの竹筒は１つの叩き石に設置されているという関係を表す。
R2 : 竹筒 ( 1c : 1c ) 叩き石
竹筒のつかが叩き石に接触しているか、離れているかを表す関係。
R3 : ポンプ ( 1 : 1 ) 竹筒
−10−

1 つのポンプが 1 つの竹筒に給水するという関係を表す。
R4 : 運転 ( 1 : 1 ) ポンプ
あるポンプにおける、水はね防止のタイミング値を定義するという関係を表す。

−11−

5.4

ステートマシン図とアクション記述

図 4.1

竹筒クラスの状態遷移図とアクション記述

図 4.2

ポンプクラスの状態遷移図とアクション記述−12−

図 4.35.5

運転クラスの状態遷移図とアクション記述

コラボレーション図コラボレーション図では、状態を持つクラス（アクティブクラス）間のイベントのやり取りを表現する。今回のモデルでは、ポンプクラス、竹筒クラス、運転クラスの３つがアクティブクラスである。<<External Entity>>は外部ドメインを表している。外部ドメインからの要求をどのクラスが受け取り、どのクラスにイベントを発行しているかを、ある 1 つのシナリオについてのみ表現するのではなく、全シナリオを 1 つの図で表現する。

−13−

図 4.4
5.6

コラボレーション図

同期サービス

同期サービスとは、他ドメインが自ドメインに対して通知や要求を行う際の手段として、自ドメインが用意しておくサービスのことである。このサービスを他ドメインが呼び出すことで、自ドメインに情報が伝わり、自ドメインが動き出すきっかけとなる。今回定義した同期サービスは
以下のとおりである。
・ Initドメインの初期化を行う。必要なインスタンスの生成や関連を張っておく。

・ Start

運転が開始されたことを知らせてもらう。

・ Stop

運転が停止されたことを知らせてもらう。

−14−

・ Touch

叩き石に竹筒が接触したことを知らせてもらう。

・ Leave

叩き石から竹筒が離れたことを知らせてもらう。

Init はシステム初期化時に呼ばれる。Init 以外の同期サービスがどのドメインから呼ばれるかは、8 章で解説する。

−15−

モデルコンパイラによる自動コード生成

6

MDA の基本概念である PIM（Platform Independent Models）から特定の技術、言語へのマ
ッピングを実現させる手段として、変換による実装がある。モデルコンパイラを利用すると変換作業が自動化される。変換による実装とは、 分析モデルの構成要素をどのようなコードで実現させるかを決定し、分析モデルからコード（実装）への変換をツールによって実現することである。
モデルコンパイラは以下の 3 つの要素で構成されている。
・ アーキタイプ（変換ルール）・ メタモデル （分析モデルの構成要素をモデル化したもの。OMG では MOF（Meta-Object
Facility）として標準化されており、ここでいうメタモデルは MOF の M2 に相当する。）
・ メカニズム

6.1（プラットフォーム依存のランタイムライブラリ）

コード生成概略

分析モデルからコードへ変換を行うには、アーキタイプ（テンプレートともいう）を使用する。
このアーキタイプには、メタモデルを基に、分析モデルの情報を取り出し、コードのどの部分に情報を埋め込むかといった内容になっている。また、ソフトウェアを実現するための共通ライブ
ラリ（リスト、キューなど）をメカニズムと呼び、変換時に利用する。１通りの変換方法では要件を満たせない場合（例えばあるクラスは永続クラスにしたいなど）には、分析者が別の変換ルールを指定することができる。これを色づけ（OMG における MDA の規格ではマークと呼ばれている）と呼ぶ。 これらアーキタイプ、メカニズム、色づけは、モデルコンパイラによって実現され、モデルコンパイラを利用することで変換による実装が可能となる。

図 6.1
6.2

モデルコンパイラによる変換

色づけ概要

色づけとは、メタモデルからの一様な変換に異なる制約を与える変換オプションである。色付
けにより、同じ分析モデルから異なる実装制約を満足するシステムが構築可能となる。

−16−

色づけ例
・クラスＡは、EEPＲＯＭ上に存在する永続クラス
・ドメイン B は別タスクで実行する・クラス B のインスタンスはヒープ領域から動的に確保し、クラス C,D は配列で静的に確保する・クラス E は使用しない（コード生成しない）
6.3

コード生成

6.3.1 環境設定
コード生成を行うには Cygwin を使用する。Cygwin での環境設定において、以下のようにモデルコンパイラの環境変数の設定とパスの設定が必要となる。
################################################## MC3020 ##################################################
setenv ROX̲MC̲ROOT̲DIR C:/mc3020 ? モデルコンパイラをインストールしたフォルダ
setenv ROX̲MC̲BIN̲DIR $ROX̲MC̲ROOT̲DIR/bin
set path=($ROX̲MC̲BIN̲DIR $path)

6.3.2 システムノードの作成
コード生成するフォルダ（システムノード）を作成する。作成したら、Cygwin のシェルを起動し、システムノードへ移動する。
ビルドツール rox_init_node を実行して、システムノード下にコード生成用のフォルダを作成する。システムノードのパス入力を求められるので、システムノードの場所を指定する。
someone[3]% rox̲init̲nodeEnter the pathname to the directory in which you wish to translate:c:/arch̲test/soze̲md ←システムノード
Upgrading application node: c:/arch̲test/soze̲md
Application translation node successfully installed!
(1) Change directory to: c:/arch̲test/soze̲md
and enter 'make help' for a list of available targets.
(2) Use 'make dom̲node' target to add a domain to the system.
'make dom̲node' without further parameters will provide examples.
(3) Edit Makefile.user to provide specific commands and options
related to your C compiler, assember, linker, etc.
someone[4]%6.3.3 OO ドメインフォルダの作成
BridgePoint で分析モデルを作成した各ドメインについて、dom_node オプションを付けてmake を実行する。
someone[4]% make dom̲node domain=sozerox̲get̲dom̲sql: INFO: 'c:/arch̲test/soze̲md/soze/schema/sql/pathfinder.sql' CREATED.
'rox̲get̲dom̲sql: INFO: Domain 'soze' using version '18
on branch 'MAIN'.

−17−

rox̲dom̲init: 'c:/arch̲test/soze̲md/soze/Makefile' CREATED.
Application domain node successfully installed!
(1) Before continuing with translation, you must register domain 'hw'
in system coloring file: system/color/registry.clr.
(2) Domain coloring files have been placed in: hw/color.
You may wish to edit these at this point before continuing with translation.
someone[5]%6.3.4 フォルダ構成
以下にフォルダ構成を示す。

図 6.2

フォルダ構成bin は使用しない。
jsp-1.4 は TOPPERS カーネルが格納されているフォルダ。
reports は生成時のログ情報ファイルが格納されている。
system は特定のドメインに依存しないシステム全体に関わるコードが格納されている。
6.3.5 色づけ
6.3.5.1 システム全体の色づけ
システム全体に関係する色付けは、${システムノード}/system/color ディレクトリ下の
カラーリングファイル（*.clr）に対して行う。
■OOA ドメインの登録
MDA のモデルで作成されているドメインを OOA ドメインと呼ぶ。OOA ドメインの名称と、キーレター、ドメイン番号を設定する。
${システムノード}/system/color/registry.clr

注意：repository_name のところは、BridgePoint の OOA ファイル xxx.ooa の xxx をいれる。
−18−

.//============================================================================.// Register OOA domain(s):.//.// RegisterOoaDomain( "repository̲name", "registered̲name", registered̲id ).//============================================================================.invoke RegisterOoaDomain( "soze", "SOZE", 1 )■手書きドメインの登録
モデル以外で作成されたドメインの説明文と、キーレター、ドメイン番号を設定する。
.//============================================================================.// Register Realized domain(s):.//.// RegisterRealizedDomain( "description", "registered̲name", registered̲id).//============================================================================.invoke RegisterRealizedDomain( "", "PIO", 100 ).invoke RegisterRealizedDomain( "", "UI", 200 )■ブリッジの登録
5.2 章で定義したドメインチャートを実現するためにドメインとブリッジの結びつけを行う。
色づけファイル：${システムノード}/system/color/bridge.clr

・OOA ドメインどうしの連結
ブリッジ関数を呼ぶ側のドメイン、外部ドメイン、呼ばれる側のドメインを、全てキーレターで設定する。OOA ドメインが 1 つしかない場合は、設定する必要はない。
.//============================================================================.// Wire Bridge Between OOA Domains using Synchronous Services:.//.// WireSynchServiceOoaBridge( "initiating̲dom", "ee̲key̲letters", "recipient̲dom" ).//============================================================================・OOA ドメインから手書きドメインへの連結
OOA ドメイン、外部ドメイン、手書きドメインのキーレター、手書きドメインのブリッジ関
数の接頭文字とヘッダファイル名を設定する。今回は、UI を IR（リモコンセンサ）、PIO を port
（ポート制御）にマッピングした（図 6.3 参照）。
.//============================================================================.// Wire Bridge Between OOA domain and Realized Domain:.//.// WireRealizedExternalEntity( "ooa̲domain̲name", "ee̲key̲letters",.// "realized̲domain̲name", "method̲prefix", "include̲file" ).//============================================================================.invoke WireRealizedExternalEntity( "SOZE", "UI", "UI", "UI", "UI̲bridge.h" ).invoke WireRealizedExternalEntity( "SOZE", "PIO", "PIO", "PIO", "PIO̲bridge.h" )

−19−

PIO

外部エンティティの定義

鹿威し

UI

UI̲bridge.cで
マッピング

PIO̲bridge.cでマッピング<<realized>>
デバイス制御<<realized>>
IR
図 6.3

<<realized>>
port

ブリッジのマッピング■他プロセスから呼ばれる同期サービス
他プロセスから呼ばれる同期サービスを登録する。
.//============================================================================.// Mark Synchronous Service as Safe for Interrupt Execution:.//.// TagSyncServiceSafeForInterrupts( "domain", "sync̲service" ).//============================================================================.invoke TagSyncServiceSafeForInterrupts( "SOZE", "Start" ).invoke TagSyncServiceSafeForInterrupts( "SOZE", "Stop" ).invoke TagSyncServiceSafeForInterrupts( "SOZE", "touch" ).invoke TagSyncServiceSafeForInterrupts( "SOZE", "leave" )■データ型の指定モデルでデータ型を定義した場合、その型が実際の言語の型とどういう関係かを設定する。
${システムノード}/system/color/datatype.clr

・データ型.//============================================================================.// Specify User Data Type Precision:.//.// TagDataTypePrecision( "domain", "dt̲name", "tagged̲name", "initial̲value" ).//============================================================================.invoke TagDataTypePrecision( "*", "UL", "unsigned long", "0" )・ポインタ型.//============================================================================.// Mapping User Data Type to an Implementation Pointer:.//.// MapDataTypeAsPointer( "domain", "dt̲name", "pointer̲type", "include̲file" ).//============================================================================−20−

■システム全体の色づけ
必要に応じて設定する。
${システムノード}/system/color/system.clr

・文字列の最大長.//============================================================================.// TagMaximumStringLength( max̲len ).//============================================================================.invoke TagMaximumStringLength( 1 )・関連インスタンス領域の最大数.//============================================================================.// TagMaximumRelationshipExtentSize( value ).//============================================================================

・選択インスタンス領域の最大数.//============================================================================.// TagMaximumSelectionExtentSize( value ).//============================================================================

・イベントキューのサイズ.//============================================================================.// TagMaximumSelfDirectedEvents( value ).// TagMaximumNonSelfDirectedEvents( value ).//============================================================================.invoke TagMaximumSelfDirectedEvents( 2 ).invoke TagMaximumNonSelfDirectedEvents( 5 )・同時に使用している OOA Timer の数の定義.//============================================================================.// TagMaximumPendingOoaTimers( value ).//============================================================================.invoke TagMaximumPendingOoaTimers( 4 )・InterleavedBridge の最大値の定義.//============================================================================.// TagMaximumInterleavedBridges( value ).//============================================================================.invoke TagMaximumInterleavedBridges( 4 )・InterleavedBridgeDataSize の定義.//============================================================================.// TagInterleavedBridgeDataSize( value ).//============================================================================.invoke TagInterleavedBridgeDataSize( 2 )6.3.5.2 OOA ドメインの色づけ
各ドメインに対する色付けは、${システムノード}/{ドメイン名}/color フォルダ下の
カラーリングファイル（*.clr）に対して行う。
■初期化関数の指定−21−

${システムノード}/{ドメイン名}/color/domain.clr

ドメインの初期化関数の関数名を設定する。
ドメインの初期化が不要な場合は、設定する必要はない。
.//============================================================================.// Tag Inititialization Function:.//.// TagInitializationFunction( "function̲name" ).//============================================================================.invoke TagInitializationFunction( "Init" )■クラスの色づけ${システムノード}/{ドメイン名}/color/object.clr

・インスタンスの最大数（デフォルト）
次項で、クラス別最大数を設定しなかったクラスは、この項での設定数の領域を確保される。
.//============================================================================.// TagSystemObjectDefaultExtentSize( value ).//============================================================================.invoke TagSystemObjectDefaultExtentSize( 1 )・インスタンスの最大数（クラス別）
クラスごとに、確保するインスタンス領域を設定できる。
.//============================================================================.// TagObjectExtentSize( "key̲letters", value ).//============================================================================

・静的インスタンスの生成.//============================================================================.// Mark Class as Having a Static Instance Population.//.// TagStaticInstancePopulation( "ss̲name", "class̲key̲letters" ).//============================================================================

・オペレーションのコード生成解除.//============================================================================.// Disable Object Operation Semantics Translation.//.// TagClassOperationTranslationOff( "object̲key̲letters", "op̲name" ).//============================================================================■イベントの優先度${システムノード}/{ドメイン名}/color/event.clr.//============================================================================.// Tag Priority Event(s):.//.// TagPriorityEvent( "event̲label", value ).//============================================================================

6.3.6 コード生成
全てのドメインのコード生成を一度にまとめて行う場合は、（A）を実行する。OOA ドメイン
−22−

を個別にコード生成する場合は、（B）を実行する。
（A） 全ドメインを一度にコード生成
gen_all オプションを付けて make を実行する。
まとめてコード生成を行うと、生成エラーの原因がどのドメインにあるのかが探しにくくなる。
設定やモデルに問題がある可能性が高い場合は、ドメイン別にコード生成したほうがよい。
someone[5]% make gen̲allrox̲get̲dom̲sql: INFO: 'c:/arch̲test/soze̲md/soze/schema/sql/pathfinder.sql' UNCHANGED.
'rox̲get̲dom̲sql: INFO: Domain 'soze' using version '18
on branch 'MAIN'.
（ログ省略）
someone[6]%（B） OOA ドメインを個別にコード生成
各ドメインについて、gen_dom オプションを付けて make を実行する。
someone[6]% make gen̲dom domain=sozerox̲get̲dom̲sql: INFO: 'c:/arch̲test/soze̲md/soze/schema/sql/pathfinder.sql' CREATED.
'rox̲get̲dom̲sql: INFO: Domain 'soze' using version '18
on branch 'MAIN'.
（ログ省略）
someone[7]%システム全体に関係するソースコードを生成するために、gen_sys オプションを付けて make を実行する。
someone[7]% make gen̲sys
rox̲sys̲init: 'c:/arch̲test/soze̲md/system/schema/sql/sys̲root.sql' CREATED.
rox̲app̲init: 'init̲seq.c' CREATED.
（ログ省略）
someone[8]%

−23−

7

設計指針
本 7 章をアーキテクチャ定義書とする。
7.1

モデルコンパイラの設計指針今回使用した PT 社のモデルコンパイラ MC-3020 は C 言語を生成する。特徴を以下に述べる。
・ パフォーマンスとリソースにおいて最適なコードに変換
・ オープンなアーキテクチャでカスタマイズ可能
・ コードとモデルのトレーサビリティが高い
・ RTOS を必要としない
・ 8 ビット、16 ビット、32 ビット CPU 対応
・ モデルレベルのトレース機能
・ ドキュメント生成
以上のように、コンパクトなコードを生成するため、メモリ制約の強い組み込みでも十分対応できるモデルコンパイラである。

7.2

モデルコンパイラのカスタマイズ

MC-3020 は RTOS を必要としないため、メインルーチンを OS のタスクとして生成するように変更する。詳しくは、TOPPERS ホームページの「JSP カーネル上でのモデルベース開発」参照。
（http://www.toppers.jp/mda.html）

7.3

タスク相関図今回は 3 つのタスクに分割した。１つはモデル部を、その他にタイマータスク、デバイス制御
タスクとした。タスク相関図を以下に示す。
アプリケーションタスク
（モデル部）

セマフォによる同期通信

イベント送信によるセマ
フォによる同期通信
タスク起床

デバイス制御タスク

タイマータスク

セマフォによる
同期通信

タイマー割り込みハンドラ

図 7.1

タスク相関図−24−

8

手書きコードとモデルとのインタフェース
ドメインチャートに基づき、ブリッジ部分、デバイス制御部分を手書きコードとした。
・ UI_beidge

IR 情報をししおどしドメインに通知するための I/F・ PIO_Bridge

ポンプの制御とランプの制御を行うための I/F・ TIM_bridge

タイマー機能・ Portデバイスのポート設定とポートセンス、ポーリングタスク

・ Ir

リモコン受光部デバイスドライバ

モデルとのインタフェースにおいては、モデル側に通知する部分は 5.6 章で説明した同期サー
ビスを用い、モデル側が呼び出す部分についてはデバイス制御側で用意している関数をブリッジを解して呼び出す。

モデル側が呼び出す関数
PIO̲pomp(bool)
PIO̲lamp(id,set)

デバイス側が呼び出す関数
SOZE̲Start()
SOZE̲Stop()
SOZE̲touch()
SOZE̲leave()
図 8.1

鹿威し

<<realized>>
デバイス制御モデルとデバイス制御とのインタフェース

−25−

9

実装環境
開発環境として、OAKS16-MINI に付属の統合開発環境 TM を使用する。TM ではホストとターゲットをシリアル接続することで通信が可能である（図 9.1 参照）。

RS-232Cシリアル接続

JP1

SW4 SW5

ホスト

ターゲット
図 9.1

9.1

開発環境

ビルド

TM に今回の使用するプロジェクトファイルである Sozem.tmk を読み込ませ、ビルドを行う。
ビルドに必要なファイルはシステムノードの下の jsp-1.4¥WORK¥OO_SOZEに格納されている（図 9.1 参照）。

−26−

図 9.2

ビルドに必要なファイル群

TM のプロジェクトには以下のファイルが登録されている。
・ モデルから自動生成されたコード・ デバイス制御コード
・ TOPPERS/Jsp カーネル、コンフィグ
図 9.2 にプロジェクトに必要なファイルを追加したところを示す。これらのファイルをビルドすることで、実行ファイル、マップファイル、ROM 化用ファイルが作成される。

−27−

図 9.3
9.2

TM のプロジェクト内容

デバッグ

OAKS16-MINI のデバッグ環境はボード、ホスト間をシリアル通信によりデバッガでデバッグが可能である。しかし、今回はログ出力用にシリアルを使用するため、デバッガは使用しなかっ
た。

−28−

9.3

ROM 化

ROM 化を行うには、OAKS16-MINI 付属の FlashSta を使用する。
１） 図 9.1 のターゲットにおけるジャンパ JP1 をショートさせ、ターゲットの電源を入れる。
２） flashSta を起動する。
３） Select Program メニューでシリアルポートを選択する。
４） Refer ボタンから、書き込むファイルを選択し（OO_Soze.mot）、OK を押す。
５） M16C Flash Start メニューで、Erase を選択し、フラッシュの中身をクリアします。
６） Program..ボタンで、書き込みを行う。
７） 書き込みが終了したら、Exit で終了する。
８） ターゲットの電源を切り、ジャンパを元に戻す。

9.4

実行

書き込み終了後は、電源 ON で鹿威しがスタートする。SW4 でポンプが始動する。また、リモコンは以下の機種に対応している。
・ RMT-H4・ RMT-V305
他の機種を追加したい場合は、ir.c の変換テーブルを拡張することで対応できる。
ログ出力を行う場合は、ターミナルソフトを立ち上げ、以下のパラメータをセットする。
Baudrate：19200
Data：8bit
Parity：none
Stop：1bit
Flow：none−29−