ソフトウェアテストシンポジウム2011
JaSST'11: Japan Symposium on Software Testing 2011

組込みリアルタイムOS向けテストツールのマルチプロセッサ拡張
2011年1月25日
株式会社デジタルクラフト
金 ハンソルJaSST`11 Tokyo1

アジェンダ
1.
2.
3.
4.
5.
6.

はじめに
シングルプロセッサ向けのテストツール
マルチプロセッサ向けのテストケース
テストツールのマルチプロセッサ拡張
実施結果と評価
まとめ

JaSST`11 Tokyo

2

背景
組込みシステムにおいてマルチプロセッサの利用が増加
低消費電力で動作し性能を向上させる方法として，シングルプロセッ
サでクロック周波数を上げるよりも，マルチプロセッサを用いて並列処理を可能にする方が有利

マルチプロセッサ向けRTOSのテスト手法の不在
マルチプロセッサに対応したRTOS に関しては，そもそもテスト経験が少ないために，テスト手法が確立されていない

マルチプロセッサ向けRTOSのテスト手法開発へ

JaSST`11 Tokyo3コンソーシアム型共同研究・技術者，研究者
・企業の経験

マルチプロセッサ向け
RTOSのテスト手法開発
・人材養成
・研究開発成果

・教員，研究者
・研究の知見・研究開発成果

名古屋大学組込みシステム研究センター（NCES）

複数の企業※ 2009年度は，シングルプロセッサ向けRTOSのAPIに着目したテスト（APIテスト）を開発

シングルプロセッサ向けRTOSのAPIテストの開発経験を活かし，マルチプロセッサ向けRTOSを対象にして，APIテストを実施
JaSST`11 Tokyo

4

TOPPERS新世代カーネル• μITRON仕様をベースとして，信頼性，安全性，ソフトウェアポータビリティを向上させるための改良・拡張• 新世代カーネルの仕様は“TOPPERS 新世代カーネル統合仕様書”にまとめられている• シングルプロセッサ向けRTOS：TOPPERS/ASPカーネル• マルチプロセッサ向けRTOS ：TOPPERS/FMPカーネル
今年度のAPIテスト対象のカーネル

http://www.toppers.jp/

TOPPERSプロジェクトとは？
••••

TOPPERSカーネルを開発/公開しているNPO法人
ITRON仕様のRTOS，ミドルウェ
ア等を開発
オープンソースで公開
実製品にも利用されている

JaSST`11 Tokyo

実用例

5

アジェンダ
1.
2.
3.
4.
5.
6.

はじめに
シングルプロセッサ向けのテストツール
マルチプロセッサ向けのテストケーステストツールのマルチプロセッサ拡張
実施結果と評価
まとめ

JaSST`11 Tokyo

6

APIテストの概要
APIテストとは？
• カーネルが提供しているAPIが統合仕様書に定められている通りに正しく振舞うことを確認するテスト• APIはシステムの状態を変更することが可能

APIテストの流れ① 統合仕様書からテスト対象であるAPI の仕様と振舞いを理解し，テストケースを抽出② テストケース毎にテストシナリオを作成③ テストシナリオを実現するためのテストプログラムを開発④ テストプログラム実行

手作
業

実施結果
テスト
仕様書 ① テスト ② テスト ③
④シナリオ
プログラム
ケース
JaSST`11 Tokyo7

テストケースとテストシナリオ
対象タスクが休止状態である場合には，対象タスクに対してタスク起動時に行うべき初期化処理が行われ，対象タスクは実行できる状態になること
テストケースの例

前状態
優先度：中のタスク1が実行状態
優先度：高のタスク2が休止状態
処理
タスク1がact_tsk(タスク2)を発行し，エラーコードとしてE_OKが返る
後状態
タスク1が実行可能状態
タスク2が実行状態
テストシナリオの例
JaSST`11 Tokyo

テストを行うAPIをテストを行うを呼ぶ時点でのシステムの状態
テストを行うAPIとその引数，戻り値APIを呼んだ後のシステムの状態※ タスク = スレッド8

ハンドコーディングでのテストプログラム開発の問題点
1. テストプログラムの可読性，保守性の低下
テストケースの実現方法が複数存在するため，開発担当者が異なることによるばらつき発生

2. テストの開発工数
ASPカーネルのAPIは121個存在し，抽出したテストケースは1,669件

3. 異なるRTOSへの流用不可
同一テストシナリオに対するRTOS毎の重複開発

テストプログラム作成をするツールの開発へ
JaSST`11 Tokyo

9

TOPPERS Test Generator（TTG）
テストプログラムを生成するツール
形式化したテストシナリオ記法
として，TESRY記法を策定

TESRY記法で記述したTESRY
データを入力値として，テストプログラムを生成

in.yaml
Test_A:
Test_A
pre_condition:
TASK1:...
do:入力
syscall: slp_tsk()()...
post_condition:
TASK1:...

out.cfg

TTG
テスト
プログラム
生成

out.hout.c
出力

ソースコードTESRYデータ
JaSST`11 Tokyo10TEst Scenario for Rtos by Yaml（TESRY）記法
テストシナリオをYAML形式で記述するもの
前状態・後状態の指定
前状態を"pre_condition"内に，後状態を "post_condition"内に記述

前状態

処理の指定
発行するAPIとその引数と戻り値を"do"内に記述

TTGは，テスト対象のAPIを実行し，後状態をチェックするプログラムを生成

処理

後状態

pre_condition:
TASK1:
type : TASK
tskpri : TSK_PRI_MID
tskstat: runningTASK2:
type : TASK
tskpri : TSK_PRI_HIGH
tskstat: dormant
do:id: TASK1
syscall: act_tsk(TASK2)ercd : E OK
post_condition:
TASK1:
tskstat: readyTASK2:
tskstat: running※YAML：造化データやオブジェクトを文字列に直列化するためのデータ形式
JaSST`11 Tokyo

11TESRY記法の時刻の指定
指定した時刻でのシステム状態をチェックするための記述

前状態“0” ：dly_tskによりTASK1は待ち状態となる“3” ：3ms後まではタスクの状態は変化なし“4” ：4ms後にTASK1は待ち解除され，実行状態になる処理※ “3”，“4”は，結果を確認する時刻（ミリ秒）を示す

TTGは，時間制御関数を用いて，RTOSのシステム時刻を制御するプログラムを生成
JaSST`11 Tokyo

後状態

pre_condition:
TASK1:
type : TASK
tskpri : TSK_PRI_MID
tskstat: runningTASK2:
type : TASK
tskpri : TSK_PRI_MID
tskstat: readydo:id: TASK1
syscall: dly_tsk(3)ercd : E OK
post_condition:0:
TASK1:
tskstat: waiting
wobjid : DELAY
lefttmo: 3
TASK2:
tskstat: running3:
TASK1:
lefttmo: 04:
TASK1:
tskstat: ready12TTGの導入効果
テストプログラムの保守性と再利用性の向上

開発規模を約1/6に圧縮※約6万行

テストシナリオからTESRYデータ作成

TESRY
データ

TTG

自動化！
手作
業

仕様書 ① テスト ② テスト
シナリオ
ケース

③

JaSST`11 TokyoTESRYデータをTTGに入力し，テストプログラムを作成※約35万行

実施結果
テスト④
プログラム
13

アジェンダ
1.
2.
3.
4.
5.
6.

はじめにシングルプロセッサ向けのテストツール
マルチプロセッサ向けのテストケース
テストツールのマルチプロセッサ拡張
実施結果と評価
まとめ

JaSST`11 Tokyo

14

TOPPERS/FMPカーネル
ASPカーネルを，マルチプロセッサ向けに機能拡張したRTOS• 複数のタスクが同時に動く• タスクは割付けられたプロセッサ上で動く• タスクの割付けプロセッサをAPIで変えられる（マイグレーション）• 他プロセッサに割付けられているタスクに対してAPIの発行• プロセッサ間の同期機構（スピンロック）• 多様なハードウェアアーキテクチャに対応
マイグレーションreadyrunning

TASK12TASK13TASK22TASK11TASK13TASK21

TOPPERS/FMP
Processor1

Processor2
JaSST`11 Tokyo

15

FMPカーネルのテストケース
ASPカーネルのテストケース

1,669件FMPカーネルのテストケース
マイグレーション機能を持つAPI増加

2,586件
全バリエーションへの対応

他プロセッサに対するAPIの発行
スピンロック
機能の追加

タスクの新規状態の追加

既存のテストツールは，FMPカーネルで追加された
既存のテストツールは，カーネルで追加された仕様に対応できていない
JaSST`11 Tokyo

16

アジェンダ
1.
2.
3.
4.

はじめにシングルプロセッサ向けのテストツール
マルチプロセッサ向けのテストケース
テストツールのマルチプロセッサ拡張① FMPカーネルで新設された要素に対する対応② プロセッサ間の同期処理実現③ プロセッサ間の時間制御の実現④ バリエーションへの対応

5. 実施結果と評価
6. まとめJaSST`11 Tokyo

17

①FMPカーネルで新設された要素に対する対応• 割付けプロセッサ（prcid）
TTGが割付けプロセッサの指定を受け付け，処理単位を割付けさせるプログラムを生成• タスクの新規状態（running-waitspin）
スピンロックを取得待ち状態の指定を受け付け，処理単位をスピンロック取得待ち状態にするプログラムを生成• スピンロック（SPINLOCK）
procidにおいて指定された処理単位に，スピンロックを取得させるプログラムを生成※処理単位：カーネルが実行制御の対象としているプログラムのこと（タスク、割込みなど）
JaSST`11 Tokyo

pre_condition:
TASK1:
type : TASK
tskstat: runningprcid : 1
TASK2:
type : TASK
tskstat: running
prcid : 2
SPN1:
type : SPINLOCK
spnstat: TSPN_LOC
procid : TASK1
CPU_STATE1:
type : CPU_STATE
loc_cpu: true
prcid : 1do:
id: TASK2
syscall: loc_spn(SPN1)
ercd : E_OK
post_condition:TASK2:
tskstat: running-waitspin
spinid : SPN1
18

②プロセッサ間の同期処理
前状態，処理，後状態の定義
TESRY記法の前状態，処理，後状態の記述
にて，全プロセッサの状態を指定できるように
拡張

次のフェーズに進む瞬間に，必ず全プロセッ
サのシステムの状態がTESRYデータに記述されている通りになっている必要がある

複数のプロセッサ間で，処理単位を実行するタイミングを合わせることが必要

JaSST`11 Tokyopre_condition:
TASK1:
type : TASK
tskstat: running
prcid : 1
TASK2:
type : TASK
tskstat: running
prcid : 2do:
id: TASK1
syscall: sus_tsk(TASK2)
ercd : E_OK
post_condition:TASK2:
tskstat: suspended19

②プロセッサ間の同期処理の実現
TTGが入力されたTESRYデータに応じて，適切なが入力されたデータに応じて，適切な同期処理を行うテストプログラムを生成する機能を追加① 指定したプロセッサ間での実行タイミ ② 他プロセッサの処理単位の特定ングを合わせる同期（BarrierSync）の処理終了を待つ同期（CheckPointSync）
Pre Condition
PE1
PE2
TASK2
TASK１
(実行状態)(実行状態)Pre Condition
TASK1(実行状態)
sta_alm(ALM1)ALM1の起動

ALM1(停止状態)
ALM1(起動状態)
CheckPoint(1)BarrierSync

CheckPoint
Sync(1)do

JaSST`11 Tokyo

20

②プロセッサ間の同期処理の実現③ 特定の処理単位が特定の状態 ④ 実行中の処理単位を終了させになるまで待つ同期（StateSync）
ないための同期（FinishSync）
PE1

Pre Condition

PE2

TASK1
(実行状態)

Post Condition

TASK2(実行状態)

TASK1(実行状態)
TASK2(実行状態)

StateSync

ref_tsk(TASK1)

FinishiSync
slp_tsk()TASK1の状態参照

TASK1(待ち状態)

終了処理

これらの同期機構を用いることにより，テストプログラムのプロセッサ間の同期処理を実現
JaSST`11 Tokyo

21

② TTGが生成する同期処理
PE1
全プロセッサの前状態作成が完了するまで待つための同期（CheckPointSync ，StateSync ）TASK1(実行状態)

TASK2(実行状態)

PE2

同期処理1
前状態確認

全プロセッサの前状態確認を終えるまで待つための同期（ BarrierSync ）同期処理2
sus_tsk(TASK2)

テスト対象のAPIの発行処理が終わるまで，他のプロセッサでの処理を，後状態へと先に進めさせないための同期（ BarrierSync ，StateSync ）後状態確認の処理が終わるまで，実行状態の処理単位を終了させないための同期（ FinishSync ）JaSST`11 TokyoTASK2(強制待ち状態)

同期処理3
後状態確認

同期処理4
終了処理
22

③プロセッサのシステム時刻制御
時刻の定義
TESRY記法の処理，後状態の記述において，全プロセッサのシステム状態を確認する時刻を指定できるように拡張

全プロセッサの時刻を揃えるためには，各プロセッサのシステム時刻を制御することが必要

次のフェーズに進む時に，必ず全プロセッサのシステムの状態がTESRYデータに記述されている通りになっている必要がある

JaSST`11 Tokyovariation:
timer_arch: local
pre_condition:
TASK1:
type : TASK
tskstat: running
prcid : 1
ALM1:
type : ALARM
almstat: TALM_STP
hdlstat: STP
prcid : 1do:
id: TASK1
syscall: msta_alm(ALM1,3,2)
ercd : E_OK
post_condition:
0:
ALM1:
almstat: TALM_STA
hdlstat: STP
lefttim: 3
prcid : 2
3:
ALM1:
lefttim: 0
4:
ALM1:
almstat: TALM_STP
hdlstat: ACTIVATE
23

③プロセッサのシステム時刻制御の問題点
タイマ方式（OSのシステム時刻管理方式）• ローカルタイマ方式 ： プロセッサ毎にシステム時刻が独立• グローバルタイマ方式 ： 全プロセッサで1つのシステム時刻を管理

タイマ方式毎に，テストにおけるシステム時刻の進め方を変えることが必要
Application
TASK1(実行状態)

TASK2(実行状態)

Application
TASK1(実行状態)

TASK2(実行状態)

TOPPERS/FMP

TOPPERS/FMP
Timer1

Timer 2Timer1

Processor1

Processor2

Processor1

ローカルタイマ方式

Processor2

グローバルタイマ方式
JaSST`11 Tokyo

24

③プロセッサのシステム時刻制御の実現

プロセッサ毎にシステム時刻を進められるように拡張
ローカルタイマ方式
Application
時間Application

TASK1(実行状態)

TASK2(実行状態)

t

時
間

TASK1
(実行状態)

TASK2(実行状態)

t
1ms進めるt+1

グローバルタイマ方式

1ms進める

1ms進める

1ms進める
1ms進める

t+2

t+1
1ms進める
t+2

TOPPERS/FMP

Timer1の時間を参照
している！

TOPPERS/FMP

Timer1

Timer 2Timer1

Processor1

Processor2

Processor1

Processor2※ASPと同じ時間の進め方で問題ない
JaSST`11 Tokyo

25

③ TTGが生成するシステム時刻制御
ALM1(停止状態)

マイグ
レーション

PE2

ALM1
msta_alm(ALM1,3,2) (停止状態)

ALM1(停止状態)

3

PE1
doの処理を終えた時を基準時刻とする

0:

TASK1
(実行状態)

後状態確認

各プロセッサの時間を進める

1ms進める

1ms進める

1ms進める

1ms進める

1ms進める

1ms進める3:
タイムアウト設定時間の次のシステム時刻にイベントが起こる
ため，1msを進める※ローカルタイマ方式のテストケースの例

0

後状態確認
1ms進める4:

1ms進める
ALM1(起動状態)

後状態確認

経過
時間

終了処理
JaSST`11 Tokyo

残り時間
26

④バリエーションへの対応
バリエーションとは？
マルチプロセッサシステムのハードウェアアーキテクチャの違い
・プロセッサの種類や数・メモリとタイマ・プロセッサ間排他制御方法

テストケースのバリエーション判別
FMPカーネルでは，バリエーションによっては実施できないテストケースが多数存在するため，実行可能なテストケースを取捨選択することが必要
テストケースは数千件に及ぶため，ユーザに実行できるテストケースを取捨選択させるのは非効率的

TTGに実行可能なテストケースを取捨選択に実行可能なテストケースを取捨選択させる機能を設けることで，実施容易性を確保※本発表では，プロセッサ数とタイマ方式のみ説明
JaSST`11 Tokyo27

④－①プロセッサ数の取捨選択
テストに必要なプロセッサ数
テストプログラムに必要なプロセッサ数より，テストが限定されることがある
テストが実行可能なTESRYデータかどうかを判断*.yaml*.yamlTTG*.yamlプロセッサ
プロセッサ数が1つ必数が2つ必数が要なテスト*.yaml 要なテスト
ケース ケース
プロセッサ数が数が3つ必要なテスト
ケース
TESRYデータ

入力
マルチプロ
セッサシス
テムのプロ
セッサ数：
2参照

プロセッサ数のバリエー
ション判別システム設定ファイル

JaSST`11 Tokyo

プロセッサ数が数が3つ必
要なテスト
ケース

選別

*.yaml*.yamlプロセッサ
プロセッサ
数が数が1つ必数が数が2つ必要なテスト
要なテスト
ケース ケース28

④－②タイマ方式の取捨選択
実行結果が異なるAPI
タイマ方式によっては，テストケースの実行結果がAPIにより変わる場合が存在
テスト実行時には，タイマ方式に応じて実行可能なテストケースのみを抽出することが必要

variation:
timer_arch: local
pre_condition:
TASK1:
type : TASK
tskstat: running
prcid : 1・・・

TESRY記法のバリエーション対応
新たにTESRY記法へ“variation”属性を設け，ローカルタイマ方式とグローバルタイマ方式で実行できるテストケースを選別*.yamlvariation:*.yamltimer_arch: local variation:
timer_arch: globalTESRYデータ

TTG

入力
ターゲットアーキテク
チャのタイマアーキテ
クチャ：global*.yaml参照タイマ方式のバリエーション
判別variation:
timer_arch: local選別*.yamlvariation:
timer_arch: global

システム設定ファイル
JaSST`11 Tokyo29

アジェンダ
1.
2.
3.
4.
5.
6.

はじめにシングルプロセッサ向けのテストツール
マルチプロセッサ向けのテストケース
テストツールのマルチプロセッサ拡張
実施結果と評価
まとめ

JaSST`11 Tokyo30

実施結果１FMPカーネルの全テストケースのカーネルの全テストケースのテストプログラムを生成することが可能
マルチプロセッサのハードウェアアーキテクチャの違いに対し、柔軟に対応することが可能
全テストケース：2,586件

同期が必要なテストケース取捨選択が必要なテストケース

2,324件

63件

176件
JaSST`11 Tokyo31

実施結果２FMPカーネルの不具合を27件検出• 冗長した分岐• 仕様と実装の違い※タスクを割付けることができる，割付け可能プロセッサのチェックが漏れていた• 意図した状態に遷移しない※過渡状態のタスクが自タスクを終了するAPIを呼び出した場合に，強制待ち状態となることがある
JaSST`11 Tokyo

32

評価
マルチプロセッサ拡張

目的としているAPIに対して，適切な同期を設けて目的としているに対して，適切な同期を設けて意図したテストを実施することができた
バリエーション対応
TTGが実行可能なテストケースを取捨選択することにより，工数を削減することができた※ TTG自体のテストも実施
JaSST`11 Tokyo33

まとめ• 名古屋大学を中心としたFMPカーネルの検証に関するコンソーシアム型研究組織は，2009年度に開発したASP
カーネルのAPIテストスイートとTTGを拡張する形で，2010年度，FMPカーネルのAPIテストスイートを開発し，APIテストを実施した• FMPカーネルに追加された仕様の対応，プロセッサ間の同期機構・システム時刻制御機能の追加，バリエーション対応により，FMPカーネルに対するAPIテストを実施することが可能となった• FMPカーネルの不具合を27件検出した

JaSST`11 Tokyo

34