目次 2 1. 目的 捉える課題 2. コンポーネントシステムについて TECS (TOPPERS Embedded Component System) 他言語との比較 3. コンポーネントシステムの適用 TOPPERS/SSPカーネルへの適用開発工程における有効性ソフトウェア構造の俯瞰における有効

TOPPERS/SSPへの

組込みコンポーネントシステム適用における

設計情報の可視化と抽象化

2011.11.17

株式会社ヴィッツ 組込制御開発部

TOPPERS TECS-WG

鵜飼 敬幸

E.C. R&D Dept.

目次

1.

目的



捉える課題

2.

コンポーネントシステムについて



TECS

(TOPPERS Embedded Component System)



他言語との比較

3.

コンポーネントシステムの適用



TOPPERS/SSPカーネルへの適用



開発工程における有効性



ソフトウェア構造の俯瞰における有効性

4.

まとめ、今後の取り組み

E.C. R&D Dept.

目的



組込みソフトウェア

の大規模化に対応する



複雑なソフトウェアの“つながり”を整理するアプローチ



多分岐・多部品を含むソフトウェア構造へのアプローチ



コンポーネントシステムの有効性を確認する



TECSを例にUML等の他言語との違いと利点



フィーチャ・バリエーションを包含するソフトウェアの理解性向上

UML

TECS

E.C. R&D Dept.

捉える課題



大規模ソフトウェアにおける課題

→課題を抱える現場では何が起こっているのか？



機能追加によるコードとリソースの肥大化



初期アーキテクチャのまま時間を理由に歪な継ぎ足しを繰り返す



機能の肥大化がリソースの拡充に直結する



製品バリエーションに対応するコードが混在



条件分岐・マクロスイッチのネストや箇所が膨大で理解性に乏しい



過剰な「変数・関数の複写」が増加の一途を辿る

ソフトウェアの保守性・解析性における観点での矛盾：

「新規の仕様追加・変更において修正ポイントが分かりやすい事」

「問題の発生が生じた場合の原因箇所が特定しやすい事」

→分かりやすければ改修時の修正時間が理由にはならない

→実装機能を必要内に集約できれば理解性低下の抑制に寄不

E.C. R&D Dept.

E.C. R&D Dept.

コンポーネントシステムについて



コンポーネントシステムの前提



ソフトウェアを何らかの部品単位で扱うための仕組み



再利用し易い形≒部品で開発する



部品化へのアプローチに用いる技術が重要なキー



ソフトウェアの継続的な改善を支援する仕組み



ライフサイクルを鑑み、長期的に継続して改善できることが重要



モデルベース開発との協調



ソフトウェアのモデルを記述しプログラムを（自動）生成する

→人間が行う作業負荷（記述量）の削減



モデル化の段階での設計検証



組込みシステムで扱える決定版が存在しなかった



汎用OSではJavaBeans, CORBA, .NETなど他多数存在



組込み開発で扱える仕組みが登場 (TECS, SaveCCT…)

E.C. R&D Dept.

TECSとは



TECS (

T

OPPERS

E

mbedded

C

omponent

S

ystem)



2009年5月にNPO法人TOPPERSから一般公開



組込みソフトウェア向けのコンポーネントシステムとして開発



TECS仕様で規定しているもの

TECS仕様

内容

コンポーネントモデル

TECSによるソフトウェア部品の構成と使い方を規定

コンポーネント図

コンポーネントモデルを図により表現する手段

コンポーネント記述言語

TECS CDL

正確なコンポーネントの定義とコンポーネントを組み

合わせてシステムを組み上げる記述言語

コンポーネント実装モデル

TECSコンポーネントを実装し、利用するモデルを定義

仕様書に提供されているモデルは一例

本

発

表

の

ポ

イ

ン

ト

E.C. R&D Dept.

ロードマップにみる位置づけ

2008

大規模化・複雑化

2007

2009

2010

2011

2012

※ リリース前のカーネルの名称は仮称

TECS

HRP2

メモリ保護，

時間保護

コンポーネント

システム対応

ASP Safety

機能安全対応

動的オブジェ

クト生成

省エネルギー

制御

SSP

最小セット

適用範囲拡大

信頼性・安全性

新世代カーネル

フルセット

ASP

新世代カーネル

仕様 スタンダード

プロファイル

FMP

マルチコア

プロセッサ拡張

高性能・省エネルギー

E.C. R&D Dept.

TECSに関して



利用者の想定スキル



コンポーネント作成者・利用者



UMLにおけるクラスが設計できる程度のスキルを想定



構造化設計に知見があること



仕様の完成度



2009年5月にVersion1を一般公開



達成機能：静的結合, ROM/RAM出力支援, 最適化, RPC, プラグイン機構

→例）コンポーネントの呼び出しをシリアル出力によって時系列でトレ

ース可能とするトレースプラグインなど



利用上の注意事項



TOPPERSライセンスに準拠



Windows, Cygwin, OSX上ので動作を確認

E.C. R&D Dept.

設計領域の位置づけ



想定するコンポーネントシステムがカバーする設

計領域の範囲



TECSを例として

UML

C

アセンブラ

静的コー

ド解析

ツール

デバッガ

分析、設計

実装

テスト

TECS

TECS

コンポーネント図

TECS CDL

トレース

プラグイン

E.C. R&D Dept.

開発の流れ



(1)TECSコンポーネント図

でソフト

ウェア構造を表現する。



関数の型である

(2)シグニチャ記

述

を行い、部品の型となる

(3)セル

タイプを記述

する。必要な部品の型

が揃ったら

(4)組上げ記述

を行う。

これらすべてを

(5)TECS CDL

を用

いて行う。



(5)

の作成物を

(6)TECS ジェネ

レータ

に通す。その結果、対象言語

の

(10)インタフェースコード、(9)

ヘッダファイル、(8)セルタイプコー

ドのテンプレート

が自動生成される。



セルタイプコードのテンプレートを元

に、コンポーネント開発者は(11)セ

ルタイプコード(C言語)を記述する。



インタフェースコードとセルタイプ

コードを、(12)コンパイルし、(13)

リンクすることで(14)アプリケーショ

ンモジュールが完成する。

(5) TECS CDL(コンポーネント記述言語) (8) テンプレート コード (2) シグニチャ記述 （インタフェースの定義） (3) セルタイプ記述 （コンポーネントの定義） (4) 組上げ記述 （コンポーネントの 構成の定義） (6) TECS ジェネレータ (9) ヘッダ (10) インタフェース コード (12)Ｃコンパイラ (11) セルタイプコード （コンポーネントの ソースコード） (13)リンカ アプリケーション 開発者 コンポーネント 開発者 (14)アプリケーショ ンモジュール (1) コンポーネント図 製品 エンドユーザー コンポーネント 仕様開発者 仕様の規定 設計 設計 利用 (7) プラグイン プラグイン 開発者 設計 

RPC



アクセス制御



トレース

E.C. R&D Dept.

結合の実装構造の標準形

cCall1_func1( )

ER tB_eEnt_func1_skel( struct

tag_sSig1_VDES *epd)

{

struct tag_tB_eEnt_DES *lepd

= (struct tag_tB_eEnt_DES *)epd;

return tB_eEnt_func1( lepd->idx );

}

ER eEnt_func1( tB_IDX idx)

{

ER ercd_ = E_OK;

tB_CB *p_cellcb;

if( tB_VALID_IDX( idx ) ){

p_cellcb = GET_CELLCB(idx);

}else{

return E_ID;

}

/*処理*/

return ercd_;

}

呼び側

受け口

関数テーブル

受け口スケルトン関数

受け口関数

tB_eEnt_func1_skel

tB_eEnt_func2_skel

tB_eEnt_func3_skel

&tB_eEnt_MT

&tB_B_CB

/* 呼び口関数マクロ（短縮形） */

#define cCall1_func1( ) ¥

tA_cCall1_func1( p_cellcb )

#define tA_cCall1_func1( p_that ) ¥

(p_that)->cCall1-

>

VMT

->¥

func1(

(p_that)->cCall1

)

typedef struct tag_tA_CB {

/* call port */

struct tag_sSig1_VDES *cCall1

;

struct tag_sSig2_VDES *cCall2;

} tA_CB;

受け口関数テーブルへの

ポインタ

受け側のセルＣＢ

呼び側のセルＣＢ

cCall1_func2( )

受け口

ディスクリプタ

受け側

tA

Ａ

tＢ

Ｂ

E.C. R&D Dept.

結合の実装構造の標準形

cCall1_func1( )

ER tB_eEnt_func1_skel( struct

tag_sSig1_VDES *epd)

{

struct tag_tB_eEnt_DES *lepd

= (struct tag_tB_eEnt_DES *)epd;

return tB_eEnt_func1( lepd->idx );

}

ER eEnt_func1( tB_IDX idx)

{

ER ercd_ = E_OK;

tB_CB *p_cellcb;

if( tB_VALID_IDX( idx ) ){

p_cellcb = GET_CELLCB(idx);

}else{

return E_ID;

}

/*処理*/

return ercd_;

}

受け口

ディスクリプタ

受け口

関数テーブル

受け口スケルトン関数

受け口関数

tB_eEnt_func1_skel

tB_eEnt_func2_skel

tB_eEnt_func3_skel

&tB_eEnt_MT

&tB_B_CB

/* 呼び口関数マクロ（短縮形） */

#define cCall1_func1( ) ¥

tA_cCall1_func1( p_cellcb )

#define tA_cCall1_func1( p_that ) ¥

(p_that)->cCall1-

>

VMT

->¥

func1(

(p_that)->cCall1

)

typedef struct tag_tA_CB {

/* call port */

struct tag_sSig1_VDES *cCall1

;

struct tag_sSig2_VDES *cCall2;

} tA_CB;

受け口関数テーブルへの

ポインタ

受け側のセルＣＢ

呼び側のセルＣＢ

cCall1_func2( )

呼び側

受け側

E.C. R&D Dept.

他言語との比較



統一モデリング言語（UML）との比較



TECSコンポーネント図≒オブジェクト図（実体の関連）に相当



コンポーネントの型＝セルタイプはTECSの概念



コンポーネントの結線は操作可能な関数束を表す



コンポーネント図では関連の存在に加えて、関数テーブル(シグニチャ)

と関連方向（呼び口、受け口）を確定する



UMLの関連は集約や多重度, 依存などの存在を表現できる

tCell

Cell1

_{シグニチャ}

Cell2

tCell

sOperation

呼び口

cCallPort

eEntryPort

受け口

クラス図：UML

オブジェクト図：UML

コンポーネント図:TECS

関連

関連

E.C. R&D Dept.

UMLとの比較

UML

TECS

備考

クラス

セルタイプ

TECSではコンポーネントの型を意味する。

セルタイプ同士の関連を表す関連図はない。

オブジェクト

セル

TECSではコンポーネントの型の実体を指す。

オブジェクト図に対してTECSコンポーネント図を用いる。

クラス内関数

シグニチャ

TECSでは関連線が関数テーブルを指し、名前をもつ。

また呼びだし側：呼び口, 呼ばれ側：受け口の名前をもつ。

UMLは矢印も可能、シグニチャは必ず方向の指定を伴う。

アクセス指定子 なし

C言語の機能に併せアクセス指定子と記号はない。

継承・派生

なし

シグニチャを踏襲することで機能の継承は可能。

tCell

Cell1

_{シグニチャ}

Cell2

tCell

sOperation

呼び口

cCallPort

eEntryPort

受け口

コンポーネント図:TECS

セルタイプ名

セル名

受け口にはセル内部

に矢印を表記する

E.C. R&D Dept.

他言語との比較



C++(Java)言語との比較



継承・派生の関係, アクセス指定子は規定しない



オブジェクト指向のプログラム言語に依存してしまう



TECSではUMLのクラスの”操作”が独立した情報

C言語で扱える点がTECSの特徴

signature

sOperation

{

シグニチャ

uint32_t Ope1( [in] int32_t arg1 );

};

celltype tCell {

セルタイプ

call sOperation cCallPort;

呼び口

entry

sOperatoin

eEntryPort;

受け口

attr { int32_t attr1 = 10000; };

var { uint32_t var1; };

};

class CApp {

クラス

private:

int m_att1;

public:

int Ope1(int arg1);

};

CApp.h(.hpp)

クラス宣言(C++)

tCell.cdl （コンポーネント記述ファイル）

シグニチャ宣言とセルタイプ宣言(TECS)

E.C. R&D Dept.

signature sOperation { シグニチャ

uint32_t Ope1( [in] uint32_t arg1 );

};

celltype tCell { セルタイプ

call sOperation cCallPort;

呼び口

entry sOperatoin eEntryPort;

受け口

attr { uint32_t attr1 = 10000; };

var { uint32_t var1; };

};

C++(Java)との比較

cell tCell Cell1 {

cCallPort

= Cell2.

eEntryPort

;

var1 = 1;

};

cell tCell Cell2 {

var1 = 2;

};

tCell

Cell1

tCell

Cell2

シグニチャ

sOperation

呼び口

cCallPort

eEntryPort

受け口

コンポーネント図

Main.cdl（コンポーネント記述ファイル）

セル宣言と全体の組上げ

構文 意味

call

呼び口

entry 受け口

attr

定数（celltype宣言時に初期化要）

var

コンポーネント内変数

tCell.cdl （コンポーネント記述ファイル）

シグニチャ宣言とセルタイプ宣言

E.C. R&D Dept.

C++(Java)言語との比較



3段階の出力手順を経る



TECSはコンポーネントの情報をエンティティ化→

独立した情報

→CDLファイルの内容が設計情報の丌足を補完する

→コンポーネント構成、結合情報を文章から言語記述へ

オブジェクト指向に

おける設計フロー

TECSの設計フロー

E.C. R&D Dept.

E.C. R&D Dept.

コンポーネントシステムの適用方針



TOPPERS/SSPカーネルへコンポーネントシステムを適用



カーネル本体に手を加えずラッパーとしてコンポーネント化する



動作の上位互換を確保する



TOPPERS/SSPカーネルのサンプルがTOPPERS/ASPカーネル

でも動作できるよう, 拡張パッケージの導入を前提とする

TOPPERS/SSPカーネル (以降、

SSP

と呼ぶ)

•TOPPERS Smallest Set Profile Kernel

•uITRON4.0仕様の「仕様準拠の最低限の条件」をベースとする小規模

リアルタイムカーネル：拡張パッケージの導入でASPと上位互換

•2011年6月10日会員早期リリース

TOPPERS/ASPカーネル (以降、

ASP

と呼ぶ)

•TOPPERS Advanced Standard Profile Kernel

•uITRON4.0仕様のスタンダードプロファイル準拠のリアルタイムカーネル

•2006年より一般公開中

E.C. R&D Dept.

コンポーネント全体像



TOPPERS/SSPカーネルに対応するコンポーネント化



ASP対応版を基にSSP版との共通化を検討した



コンポーネント記述はSSP/ASP共通セルで全て同じ



サービスの機能単位でコンポーネント化した



組み合わせによりセルを新設



周期タスク等を複合セルによりコンポーネント化



複合コンポーネントについては本発表では触れない

tTask

tInitializeRoutine

tTerminateRoutine

tISR

tConfigInterrupt

tISRWithConfigInterrupt

tCyclicHandler

tCyclicTask

tCyclicTaskActivator

tAlarmHandler

tSemaphore

tEventflag

tDataqueue

tPriorityDataqueue

tFixedSizeMemoryPool

tKernel

TOPPERS/SSPコンポーネント全体像

拡張パッケージ対応セル

SSP/ASP共通セル

ASP対応セル

tISR

tTask

tKernel

SSP

カーネル

※カーネルに対応したセ

ル同士のコンポーネント

間の結合は、既存コード

をラップする手段とした

ため、アプリケーションを

実装した際に出現する

（図は結合のイメージ）

SSP仕様

E.C. R&D Dept.

コンポーネント全体像



SSPシリアル出力サンプルプログラムへの適応



シリアル接続のターミナルから入力文字を待機



入力文字に応じて、タスクの起動,終了,CPU例外発生を行う

サンプルプログラム TECSコンポーネント図

tCyclicHandler

CyclicHandler

tSample1

Sample1

tTask

InitTask

tTask

MainTask

tTask

Task

tKernel

SSPKernel

tSerial

Serial

※2重線は能動的に動

作するアクティブセル

E.C. R&D Dept.

適用結果



コンポーネント化の恩恵を確認



コンポーネントのオーバーヘッドを小さく抑えられる



SSPのような小さなカーネルでも利用を検討できる



C++のようなオブジェクト指向的な概念を、これまで

組込開発に持ち込めなかった点の打開策になり得る

文字送信における比較

1文字

5文字

コンポーネント（最適化なし）

31.27us

69.16us

コンポーネント（最適化あり）

29.16us

64.18us

非コンポーネント

29.15us

63.47us

非コンポーネント（インライン）

27.00us

61.59us

メモリ消費における比較

text

data

bss

rodata

total

コンポーネント（最適化なし）

3,632

100

512

190

4,436

コンポーネント（最適化あり）

3,120

100

512

88

3,820

非コンポーネント

3,632

0

568

100

4,300

E.C. R&D Dept.

コンポーネントシステム適用工程



ASP対応版を基としたので、

(1)コンポ

ーネント図

の組み替え以外、

(4)組上

げ記述

によるコンポーネント結合まで、

修正作業が発生しない。コンポーネン

ト自体はASP版そのもの。



(6)TECSジェネレータ

により

(9)ヘッダ

(10)インタフェースコード

が自動で出

力される。



(11) セルタイプコード

をSSPに併せて

実装する。ASPの仕様にのみ存在する

機能の関数コードを削除する。



ASPのみに使用するコードを

(13)リン

カ

の対象から除外する。

コンポーネント図（組み替え）以外は、C言

語のコンポーネントコード実装と、リン

ク対象の変更のみ。

(5) TECS CDL(コンポーネント記述言語) (8) テンプレート コード (2) シグニチャ記述 （インタフェースの定義） (3) セルタイプ記述 （コンポーネントの定義） (4) 組上げ記述 （コンポーネントの 構成の定義） (6) TECS ジェネレータ (9) ヘッダ (10) インタフェース コード (12)Ｃコンパイラ (11) セルタイプコード （コンポーネントの ソースコード） (13)リンカ アプリケーション 開発者 コンポーネント 開発者 (14)アプリケーショ ンモジュール (1) コンポーネント図 製品 エンドユーザー コンポーネント 仕様開発者 仕様の規定 設計 設計 利用 (7) プラグイン プラグイン 開発者 設計 

RPC



アクセス制御



トレース

ソフトウェアのアーキテクチャ設計を、

コーディング工程まで

揺らぎなく引き

継いでいる

から簡略化可能である。

E.C. R&D Dept.

適用における考察



コンポーネントの適用における考察



文章による設計内容には多分に曖昧

さを含んでいる



文章でもガイドワードなど表記ルールを

適用することで曖昧さ抑制できるが？

→形式化した記述を制約に課している

のと同じ（ある種のプログラム言語）

→人間の読解の手間が必要、読解の

過程でミスの混入リスクがある



下位工程は文章から想像力を働かせ

て元の設計を復元する努力をしていた



コンポーネントシステムは曖昧性の排除

を行っている

アーキテクトの

最終イメージ

アーキテクト

ドキュメント記述

ダイアグラム記述

詳細設計担当

プログラマ

コンポーネント

システム

ソフトウェア構造設計

文章

曖昧さを含む

完全一致する事の方が難しい

構造一致

文章による補完では、ソフトウェア構造

設計を方式設計工程で行うのではなく、

実はより下位の工程で行うのと同義

E.C. R&D Dept.

適用結果



人間によるプログラム記述量の減尐



コンポーネントアーキテクチャの記述が丌要



コンポーネント間のグルーコードまで自動生成



コーディング工程ではコンポーネント内のローカル関

数や、シグニチャで定義した関数の実装に専念可能

記述量

非依存部 依存部 グルー CDL

total

コンポーネント

456

185

0

125

766

非コンポーネント 549

278

119

0

946

※ASPカーネルの計数値

E.C. R&D Dept.

開発工程における有効性

開発工程で俯瞰してみると・・・



コンポーネント結合はソフトウェア設計に影響



詳細設計あるいは実装工程で補完を行っていた構造設

計を方式設計工程へ戻す→数段階抽象化している

出典：SEC 組込みソフトウェア向け開発プロセスガイド

マクロスイッチ

条件分岐

コメントによる設計情報

（曖昧さを含む）

コンポーネント結合

コンポーネント記述

統一された結合規則

ソフトウェアアーキテクトの意識との乖離を抑止する

E.C. R&D Dept.

ソフトウェア構造の俯瞰における有効性



開発ターゲットの違い・バリエーションの検討



例えば機能性は同じで性能が異なる部品を実装する



C言語のマクロや条件分岐を使った実装の場合



判定条件の数値の理解が必要になる（ドキュメントやコメントを読む）



出現箇所が多種多数に及ぶ場合の解析性低下は著しい



コンポーネント図・記述から対象ソースコードは一意に特定



条件分岐の抑制や余剰コードの排除でROM/RAMの節約や、処理時

間の最適化というメリットを享受することもできる

#ifdef Target1

Switch (Target )

{

case Target1:

baudrate = 9600;

…

#else

…

tCyclicHan dler CyclicHan dler tSample1 Sample1 tTask InitTask tTask MainTask tTask Task tKernel SSPKernel

tSerial

Serial2

tCyclicHan dler CyclicHan dler tSample1 Sample1 tTask InitTask tTask MainTask tTask Task tKernel SSPKernel

tSerial

Serial1

テキストから図へ

解析性の向上

更なるメリットとして

省ROM/RAM化

処理時間の最適化

cell tSerial Serial1 {

baudrate

= 9600;

channel = 1;

};

cell tSerial Serial2 {

baudrate

= 4800;

channel = 2;

E.C. R&D Dept.

ソフトウェア構造の俯瞰における有効性



フィーチャの違い・プロダクトライン的構想の検討



例えば仕向けの違いで必要な部品（構成）を切り替える



ソースコード内に全ての機能を残しておくアプローチでは



場合によっては余剰コード自体を取り去ることで品質要件に変化が出

る事がリスクとなってしまう→ハード拡充に始まるデメリットが顕在化



コンポーネントシステムは図から結合情報を自動で補完する

Switch (Target )

{

case Target1:

SendSerial();

break;

…

case Target2:

SendCAN();

…

tCyclicHan dler CyclicHan dler tSample1 Sample1 tTask InitTask tTask MainTask tTask Task tKernel SSPKernel

tCAN

CAN1

tCyclicHan dler CyclicHan dler tSample1 Sample1 tTask InitTask tTask MainTask tTask Task tKernel SSPKernel

tSerial

Serial1

テキストから図へ

構成の一意の特定

視覚化による理解

性向上

cell tSerial Serial1 {

baudrate

= 9600;

channel = 1;

};

cell tCAN CAN1 {

baudrate = BD5K;

channel = 2;

};

コンポーネント図からコンポーネント記述へ

E.C. R&D Dept.

E.C. R&D Dept.

まとめ



条件分岐やマクロによる実行コードの切り替えを用いた

バリーエーションを実現するような複雑なソフトウェア構

造を、解析性に貢献しつつ管理する手法を示した



機能の異なるソフトウェア部品の組み合わせによるフィ

ーチャやプロダクトライン対象部品の管理手法を示した



C言語を用いた組込みソフトウェア開発において、ソフト

ウェアモデルからソースコードを自動生成する手法を用

いて、アーキテクチャ設計を上位工程へ抽象化する具体

的な方法を示した

E.C. R&D Dept.

今後の取り組み



形式記述との連携



先に紹介したプラグイン機構を用いて、形式記述の

仕組みと連携する試み



ハードウェア／ソフトウェア間の協調設計



FPGAなどの再構成可能なハードウェアと、ソフトウェ

アとの役割分担を制御する試み



互換性を確保した記述の拡張



上下位互換性の検討



バイナリ流通や動的結合に対応する備えとして

E.C. R&D Dept.

参考文献

1.

OMG: CORBA Component Model 4.0,

http://www.omg.org/technology/documents/formal/components.htm

.

2.

Microsoft Corporation: .NET Framework Conceptual Overview,

http://msdn.microsoft.com/en-us/library/zw4w595w.aspx

.

3.

ORACLE: Enterprise JavaBeans Technology,

http://www.oracle.com/us/products/tools/ejb-141389.html

.

4.

NPO法人TOPPERSプロジェクト: TOPPERS/SSPカーネル,

https://www.toppers.jp/members.html#early

.

5.

NPO法人TOPPERSプロジェクト: TOPPERS/ASPカーネル,

https://www.toppers.jp/asp-kernel.html

.

6.

OMG: Unified Modeling Language (UML),

E.C. R&D Dept.

ありがとうございました

発表にあたり協力頂いた

TOPPERS TECS-WGの皆さまに

感謝致します