tag:blogger.com,1999:blog-84565251320334599362024-11-01T19:34:14.881+09:00Embedded-Note lagavulin1956tfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.comBlogger25125tag:blogger.com,1999:blog-8456525132033459936.post-80718509548289659522011-03-27T15:09:00.001+09:002011-03-27T15:10:06.622+09:00NuSMVで非決定性状態マシン非決定性の状態遷移があると実装には落とせないので、非決定性の有無は設計検証の対象になる。しかし、要求仕様の段階では非決定性のままで検証したいこともある。たとえば、ランダムな振る舞いをする外部デバイス等を環境モデルに取り込む場合などである。
ASSIGN
next (s) :=
case
T_S1 : Sl;
T_S2 : S2;
T_S3 : S3;
!inS & next(inS) : S1; -- start state
TRUE : s;
&tfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com0tag:blogger.com,1999:blog-8456525132033459936.post-10572643917493489832011-03-23T00:11:00.001+09:002011-03-23T00:20:19.868+09:00NuSMVで階層化状態マシンNuSMVはSPINよりもモデル化の自由度が大きくUML等で出てくる階層化状態マシンをAND状態も含めてモデル化することができる。
まず、与えられた階層化状態マシンについて二つの集合を作成する。
Τ : root stateの集合、トップ状態とAND状態の子供
Α : atomic stateの集合とAND状態
ある状態 s について v(s)は直近の親を表すとする。Tは v(s) = s ∈ T となるような集合。
Tの要素はNuSMVの列挙型変数とする。そして、列挙型の要素 b は、
a ∈ T の時に、v(b) ∈ a となるようなb
によって構成される。
この状態図の場合
VAR
M: {P, Q}; R: {UI, U2, V}; S: {tfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com0tag:blogger.com,1999:blog-8456525132033459936.post-35164400198719650902011-03-21T17:19:00.002+09:002011-03-28T16:54:28.702+09:00NuSMVでタイミング解析モデル検査ツールのNuSMVを使用してタイミング解析が可能である。従来のCPU使用率に基づく手法に比べて悲観的な結果が出ることもなく、起動オフセットも含めて網羅的な検証が可能である。さらに、最小応答時間と最大応答時間を求めることもできる。ただし、従来の手法に比べて計算時間が長くなる。
Cheddarを紹介した際の問題をNuSMVで解いてみる。
まず、基本的な定数を定義する
DEFINE
C1:=20; C2:=40; C3:=100; -- Ciは実行時間
D1:=100; D2:=150; D3:=350; -- Diはデッドライン=起動周期
次に変数
VARc1:0..C1; -- ci: taskiの実行残り時間c2:0..C2; c3:0..C3; d1:0..D1; -- di: デットラインまでの時間、起動オフセットd2:0..D2; tfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com0tag:blogger.com,1999:blog-8456525132033459936.post-33622756115564297152011-02-11T14:57:00.000+09:002011-02-11T14:57:06.339+09:00Generating Method for Combinatorial Testing Data Using Propositional Normal Form ConversionIn an embedded system which operates multiple devices, combinatorial testing of multiple events is needed to verify proper behavior of the system. However, the number of test cases becomes huge, especially for the order in which events happen in parallel, and it is difficult to carry out all cases. So many methods to generate minimum test data set have been already proposed, but their tfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com0tag:blogger.com,1999:blog-8456525132033459936.post-30534319015609396352010-12-09T11:38:00.003+09:002010-12-09T16:50:09.122+09:00決定論的故障⇒決定論的原因故障systematic failureを決定論的故障と呼ぶことにかなり違和感があった。ソフトにバグがあれば必ずおかしな動作をする。これが決定論的な動作で、そのような故障原因は安全ライフサイクルの様なシステマティックなアプローチで解決する。と言うことだと理解している。間違っていたら指摘してもらいたい。
日本語は原因の特徴について述べていて、英語は対処法について述べている。ここに違和感があったのだが、Webを見ていたら決定論的原因故障と訳している場合も多く、こちらであれば、「決定論的原因による故障」と解釈することで何とか納得できる。
決定論的原因とは原因箇所を論理的に絞り込めたり、それを証明することができるタイプの故障で、またそのことによって完全に取り除くことができる故障原因と定義してはどうだろうか。
例えばコンポーネントがA,B,Cとあってある機能Fが動かなくなってコンポーネン
トBtfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com0tag:blogger.com,1999:blog-8456525132033459936.post-15262387000782683542010-10-09T22:15:00.000+09:002010-10-09T22:15:52.480+09:00Cheddar: タイミング解析ツールフリーのタイミング解析ツールCheddarを使ってみた。Windows版をダウンロードして解凍するとexeが出てくるのでそれをダブルクリックすれば立ち上がる。
一通り使えるだけの情報を提供するマニュアルもあるし、そこから関連する論文へのインデックスも付いているので時間を掛ければ色々面白いことができそうだ。
まず、プロセッサを定義する。Edit>Update Processorでスケジューラを指定する。RTOSの優先度ベースのスケジューリングに対応するのはHighest Priority Firstなので、これを選んでみる。この他にデッドラインモノトニックとか定番のモノが用意されている。Rate Monotonicを選べばタスク優先度を付けなくても良いので最初はこの方が良いかも知れない。独自に定義することもできる。
次にEdit>Update address spaceでtfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com0tag:blogger.com,1999:blog-8456525132033459936.post-65836061060158008542010-07-22T10:46:00.000+09:002010-07-22T10:46:00.438+09:00implyとequivalent及びBranch coverageとDecision coverageTwitterで話していたがまとめて話さないと伝わらないので、まとめてみる
ここに、Branch/Decision Testingという記事があって、冒頭に
For components with one entry point 100% Branch Coverage is equivalent to 100% Decision Coverage (入り口が一つのコンポーネントに対しては100%BCは100%DCと等しい)
と書いてある。
equivalentとは?
等しいのだからBDが100%ならDCも100%になりその逆も成立する。等価性には対称律が成立する。
入り口が複数あるとは?
構造化プログラム言語を使っていると関数の入り口は一つに決まっているが、昔のFortranのentry文を使うとサブルーチンの入り口を複数作ることができる。今でもOSのディスパッチャ等はマルチtfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com0tag:blogger.com,1999:blog-8456525132033459936.post-82887881660579926412010-07-18T15:13:00.002+09:002010-07-18T23:25:36.263+09:00Wot, no chickens?Javaにはリアルタイム性が無いと言うと、ガベージコレクタの話題かと思うが、それだけではない。以下の二つも問題である。
Javaには待ち行列が二つある。Synchronizedによる待ち行列とwait/notifyによる待ち行列である。この二つの待ち行列のせいでライブロックが発生する。これはJava仕様の問題だろう。
それからもう一つ、待ち行列がFIFOではなくLIFOになっていることである。どこまでがJava仕様でどこからがVM実装依存なのか分からないが、現在ダウンロードできるJavaの実行環境はLIFOになっている。LIFOだと後から来たスレッドが先に処理されるので、オーバーロード時には最初に来たスレッドは永遠に待たされる。優先度付き待ち行列のポリシーはVM実装時に変更できないとどこかで読んだ気がするが、この記憶が正しければJava仕様の問題だろう。
これだけJavaが使われていtfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com0tag:blogger.com,1999:blog-8456525132033459936.post-32432880961722937982010-06-03T09:00:00.002+09:002010-07-01T07:51:27.275+09:00回文数式作成プログラムプログラム検証ツールを使って回文数式を作る。
例えば
42+46=64+24
// 回文数式作成
void main()
{
int a1, a2, b1, b2, A1, A2, B1, B2;
__CPROVER_assume(a1 > 0 && a1 <10 && a2 > 0 && a2 < 10 && b1 > 0 && b1 < 10 && b2 > 0 && b2 < 10);
A1 = 10*a1 + a2;
A2 = 10*a2 + a1;
B1 = 10*b1 + b2;
&tfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com0tag:blogger.com,1999:blog-8456525132033459936.post-87570292316997798582010-05-30T14:17:00.002+09:002010-05-30T20:10:30.800+09:00単体テストできない関数ヨーロッパの鉄道の安全規格[1]で一番厳しいSIL4ではブランチテストの100%カバレッジが求められるらしい。if文がネストしている複雑な関数の場合、そこにたどり着く入力データを作り出すのはなかなか難しい。CBMCを使って簡単にテストデータを生成する方法としてassert(0)を埋め込む方法がある。到達したい場所にassert(0)を仕込んで置いてCBMCで検証をすればCBMCが向きになってそこまで行って転けてくれるのでたどり着く方法が明確になる。必要があればprintf文も仕込んでおく、さらにテキストファイルに書き出すようにすれば、テストツールに掛けられる形でテストケースを得ることができる。
しかし、この方法も構造化されたプログラムでないとうまく行かない。構造化されたプログラムというのは、逐次、分岐、繰り返し構造だけでできているプログラムで、前方に跳ぶgoto文とか入れ子にならないtfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com0tag:blogger.com,1999:blog-8456525132033459936.post-34473281652086642622010-04-25T12:56:00.003+09:002010-04-25T13:16:01.781+09:00PDD その2インタフェース誌にPDDのアイディアを書いた[1]。基本的な手順は、
1. プログラムの目的を事後条件として表す。assert文で表現する。2. 入力条件を場合分けし、それを事前条件とする。assume文で表現する。3. assume文の範囲でコーディングをおこない、検証をパスさせる。4. パスさせる過程で反例を分析して、分析結果はコーディングまたは事前条件に反映させる。5. 残りの入力条件について同様に検証をパスさせる。6. 全てtfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com0tag:blogger.com,1999:blog-8456525132033459936.post-23808218592657377582010-04-18T01:56:00.003+09:002010-04-18T13:17:38.756+09:00レビューの信頼性レビューする時、間違っているのに正しいとしてしまう間違いと、正しいのに間違っているとしてしまう間違いの二通りの間違いがある。前者をtype-1、後者をtype-2の間違いとする。またそれぞれの発生確率をe1、e2とする。要するにtype-1は見落とし、type-2は濡れ衣を着せてしまうことに対応する。
一人で2回レビューする時、1回目で間違いとしたものは見直さない場合には、見落としの確率は低くなるが、濡れ衣の確率は高くなる。xをe1またはe2としてプロットすると上図のようになる。つまり、見落としの方は二回連続で見落とさない限り検出されるので、見落とし確率はe1*e1になる。0 < e1 < 1なので小さくなりレビューの信頼性は向上する。濡れ衣は一度着せられてしまうと脱げないので、着せられてしまう確率は高くなるのである。濡れ衣を着せられない確率は1-e2で二回連続で着せられtfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com1tag:blogger.com,1999:blog-8456525132033459936.post-32980921466705087722010-03-31T01:33:00.002+09:002010-10-02T08:02:36.948+09:00TDD ⇒ PDDダイクストラは、テストでバグの存在は示せるがバグのないことは示せないと言っていた。一方で、TDDはテストを重ねながらプログラミングをおこない、用意したテストが全部通ったらプログラム完成と言うアプローチだ。と誤解しやすいが実は単なる開発プロセスに対する提案である(10/2)。
欲しいのはバグはあるかも知れないが取りあえず動作する綺麗なコードではなく、まずバグのないコードだ。
この点を改善するにはどうするか。実は良いアイディアが浮かんだ。自動テストツールではなく、プログラム検証ツールを使用して正しいことを証明しながらプログラミングをおこなうPDD(Proof driven development)だ。
プログラムSの証明とは、Qを事前条件、Rを事後条件として、{Q} S {P}が恒真であることを示すことだ。たとえば、二つの整数x, yを与えられてxが大きい値になるように、値を入れ替えるtfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com3tag:blogger.com,1999:blog-8456525132033459936.post-16347898991995151692010-03-04T15:33:00.061+09:002010-03-11T05:06:08.158+09:00モデル化のセンスUse Caseモデルを作ろうとするとDFDのような数珠つなぎの絵を描いてしまう、なぜだろうか、と聞かれたのでしばらく考えていた。たまたまUML&FMと言う形式手法関係のIEEEのワークショップの資料を見ていたところ下図のような絵があった。
きっとMulti-viewのところの知識か何かが不足しているのでそのようなことになるのではないか。例えば、DFDの使い方には長けているので何でも本人は書けてしまうし良く理解できている。何でもExcelで書いてしまう人などこのタイプは多い。自分用のメモとしては良いかも知れないが、他の人には理解してもらえない。変てこな図を書いていても作るものは作っているのであれば、抽象化軸やアーキテクチャ軸は頭の中に存在しているのだろう。Multi-view軸のところには色々なタイやグラムが並んでいるが目的に応じて使い分けることをUMLは意図している。下の図のtfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com2tag:blogger.com,1999:blog-8456525132033459936.post-45054785267912624812010-02-26T23:55:00.006+09:002010-03-31T01:37:59.579+09:00ソースコードの論理構造要求を構造化した要求木と言う考え方を2010年2月号のインタフェース誌で紹介した。
要求管理ツールなどで要求のトレーサビリティを管理する例はあるが、それは単なる関係ではなくて論理的関係である。このことを利用して知識ベース化しようと言う考え方である。
今月のインタフェース誌(2010年4月号)はこの続きで、要求木の一番下のソースコードとの関係をプログラム検証ツールCBMC ( Bounded Model Checking for ANSI-C )を利用してソースコードも論理式にしてしまって要求木に組み込んで見ようと言う試みである。
上の図でCが左のソースコードの論理式表現になる。Rがアサーションでソースコードが満たすべき仕様になる。要求木の図ではReq6とかReq7にあたる。
CBMCはソースコードを論理化するのが目的ではなくPolySpaceと同じようなソースコード検証をするためのtfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com1tag:blogger.com,1999:blog-8456525132033459936.post-70016023205438457152010-02-23T18:25:00.005+09:002010-06-16T10:20:31.448+09:00Simicsエリクソンの基地局ソフトのデバッグのために開発されたシミュレーション用のツールSimicsを、ウィンドリバーのセミナーで見てきた。シミックスと読むらしい。
http://www.co-nss.co.jp/products/middleware/simics.html
バーチャテック・ジャパンと言うところが日本法人らしいがまだ日本語のホームページがない。英語のページに行くとホワイトペーパーがそろっている。ゾウムシのような虫の写真付きのホワイトペーパーがあった。スエーデンの虫だろうか?
ボードレベルのシミュレーションを行うことができる。システムLSIのシミュレーション等でサイクルアキュレートだと数ミリ秒分の実行で一晩かかったりするが、このツールはボードを仮想化してハードウェア部分のメモリとかバスのシミュレーションはやらないのでサクサクと動く。Windowsの時計のシミュレーションのデモtfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com0tag:blogger.com,1999:blog-8456525132033459936.post-42420732667600083572010-02-20T13:09:00.022+09:002010-03-22T02:59:21.464+09:00原因結果グラフ-2 MASK結果グラフで A masks B とした場合の扱いは
1) A⇒￢B
2) Aが真ならBは未定義(三値論理の利用)
3) Aの真偽による場合分け
の三通りが考えられる。
1)の場合REQ制約の否定として表現できる。CEGTestの場合は、問い合わせ中だが、REQの否定を柔軟に利用できればMASKは要らなくなってしまう。 赤い四角で囲った部分を表現することが出来るので1)の意味でのMASKは特に必要ない。
青丸で囲んだところはちょっと怪しい。と言うか括弧で括るような、否定を取る優先順位を決めなければならない。そう言うことを考えなくても良いようにREQとMASKが定義してあると言うのは合理的かも知れない。ただし、最近FXの秋山氏の指摘で新たな謎が生まれた。MASKは結果側に付ける[1]と言うものである。もしそうなら原因結果グラフは結構簡単で使いやすいものになる気がする。この謎tfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com0tag:blogger.com,1999:blog-8456525132033459936.post-30264999813341085282010-02-16T10:01:00.021+09:002011-07-14T01:35:46.955+09:00原因結果グラフを利用した形式仕様記述形式仕様記述というと述語論理から始まるが、命題論理でもやれることは多い。その一つが原因結果グラフである。これについては以前インタフェース誌[1]に書いたことがある。しかし、最近ニフィのK氏がCEGTestをリリースされたのだがどうも仕様が違う様なので悩んでいる。また、FXのA氏のツール(X-CEG)とも違う様だ。特にMASKの扱いが違う。それで本当はどうなのか少し整理しておきたい。インタフェース誌[1]に掲載した変換規則を以下に示す。元ネタは[2]である。EとOは要素数が3ヶ以上の時は論理式の形が変わる。それは[1]を参照。
原因結果グラフの本来の使い方はテストケースを絞り込むことであり、仕様を記述することではない。仕様記述としてはMC/DC等の手法を使って絞り込む前の論理式表現に興味がある。同じ文章から原因結果グラフを作っても人によって違うグラフが出来ることが多い。それは元の文章のtfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com0tag:blogger.com,1999:blog-8456525132033459936.post-21709969296644750152010-02-13T01:23:00.005+09:002010-02-13T11:47:44.482+09:00Watchdogの設計-2 リセットのモデルWDTの動作モデルを作ってみる。基本的な動作を並列合成することで目的の状態マシンを生成することが出来れば、要求仕様を組み合わせてそれを満たす状態マシンを作ることが出来る。そのサンプルとしてマルチタスク下のWDTの挙動を利用する。
動作の合成
定周期タスクの動作は左図で表される。これをLTSAモデルにすると
CTask = (body->alive->CTask).
となる。WDTはCTaskがbody部分で無限ループになるかデッドロックになってフラグにaliveを書き込まないとシステムリセットを掛ける。リセット動作は
ResetProcess = (Allaction->ResetProcess|reset->shutdown->END).
と書くことが出来る。ここでAllactionは、
set Allaction = {body, alive}tfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com0tag:blogger.com,1999:blog-8456525132033459936.post-63867734692770712812010-02-12T01:01:00.001+09:002010-02-12T01:16:20.817+09:00形式手法あれこれ形式手法(Formal Method)と言われる分野にはおおざっぱに分けて形式仕様記述とモデル検査がある。それから、形式的開発手法というか開発プロセス的にまとめたものがある。
形式仕様記述ではVDM, Z等が有名である。モデル検査ではSPIN, NuSMV等が有名である。形式的開発手法にはB-method,RAISE等がありどれが有名と言うことはない。
VDMはツールの名前でもあるし言語の名前、あるいは記述スタイルを指して使われるが、Zは言語あるいは記法であり適当な専用ツールが無い。Zは好きだけど動かないからVDMを使う人は多い。それじゃZは使えないかと言うと事例はある。日本では使うの使わねぇのと言う段階から使えるのか使えないのかと言う議論が始まるまでに10年掛かったが、海外には成功事例も失敗事例もちゃんとある。
Zは集合論とλ計算など数学とコンピュータサイエンスの合わせ技で構成さtfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com0tag:blogger.com,1999:blog-8456525132033459936.post-90817923096939213152010-02-11T12:23:00.006+09:002010-02-11T13:03:14.597+09:00USP友の会業務系の話題だけれど、おもしろい人たちの存在を昨日知ってしまった。かなりの実績もあるという。RDBを使わずにシェルスクリプトだけで業務システムを構築する。開発費も運営費もIBMとか富士通がやる場合の1/10になるという。しかもパフォーマンスも良い。宇宙を飛ぶ怪しいムササビも良い。
データを書き足すだけで更新しない、検索しやすいようなファイルパスを設定する、書き込むデータ毎に別ファイルにする、ベースデータ以外は毎朝一から作り直すのでいつも新鮮(データの整合性が保たれる)、等々常識を覆すアイディア満載のシステム。既存のSIerは真っ青かも。
サブルーチン何か作らない。巨大なメインがあれば良い、その方が、早いから。
再利用なんかしない、似たプログラムを見つけてコピーして直して使う。クローンの何が悪いのさ
オブジェクト指向なんて要らない、インスタンスがあればいい。仕事をするのはインスタンスだ。tfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com2tag:blogger.com,1999:blog-8456525132033459936.post-77803027157740969802010-02-06T03:46:00.012+09:002010-02-08T09:26:00.469+09:00信頼性について-2: MTTFによるテストクリーンルーム手法では品質保証を目的としたテストの指標としてMTTF(Mean Time To Failure)を利用する。そして、バグ密度のような指標は品質にとっては意味がないと言っている。クリーンルーム手法はホーア理論に基づいた形式手法の一種である。
また一方、ソースコード検証ツールであるPolySpaceのWebセミナーは
プログラム検証によって発見されたソースコードのバグを100%取る必要は無い。95%ぐらいでよい。
機能テストとプログラム検証は違う。
プログラム検証をやっても機能テストは必要だ。5%の取り残しバグがあっても機能テストをパスすれば良い。
と言っている。
クリーンルームの方は、機能テストをすればプログラム検証は必要ないという言い方になっていて一見すると別のようだが、障害の有無が重要でありfaultの数は重要でないと言う点では一致している気がする。バグは欠陥(tfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com0tag:blogger.com,1999:blog-8456525132033459936.post-49422389739920730562010-02-04T23:40:00.017+09:002010-02-08T00:39:31.281+09:00信頼性について品質と同じようにわかり辛いのが信頼性だ。ソフトにバグが有ると品質も信頼性も低くなることは依存はないと思うが、バグが無ければ高品質で高信頼性かというとそうでもない。仮にそうだとしてもバグの無いソフトはない、あるいはバグの無いことを証明することはできないとも言われるので、ソフトについて高品質とか高信頼性とか言うと嘘つきになって、話が終わってしまう。そんな訳だからあまり人と議論してもまともな議論にならないことが多い。もっと定量的な定義が必要である。
品質属性の一つとして信頼性があるというのが一般的なので、信頼性から考えてみたい。障害が起きるかどうかは確率的事象と考えることが妥当である。f(t)を障害が起きる確率密度関数とすると。ある時刻tまでに障害が起きる確率分布関数F(t)は以下のようになる。
障害を広辞苑で引くと「2. 身体器官に何らかのさわりがあって機能を果さないこと」と出ている。この何tfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com0tag:blogger.com,1999:blog-8456525132033459936.post-92158938154772314032010-02-04T22:07:00.002+09:002010-08-29T14:16:45.413+09:00PrismテクマトリクスでのPrismの説明会に参加した。Prismは、プログラムの動的解析をするツールである。
入力としては、デバッグ情報付きのオブジェクトコード、実際に実行して得たトレース情報、ソースコードである。
マルチタスクやマルチコア環境でのチューニングやシングルコアからマルチコアに移行する際の設計支援に利用することが出来る。ソースコードを入力として利用するのでソースコードを解析するのかと思っていたら、解析対象は実行トレースであった。別々のスレッドが同じアドレスにアクセスしていたらソースコードを参照してアラートを上げてくれる仕組みである。従って、実行した部分のみが解析対象になる。排他制御が必要なのに排他制御されてないと、タイミング上実際に不具合が無くても不具合の可能性として検出する。また、アドレスを見ているので、ポインターのポインターのそのまたポインターによる参照でも検出することがtfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com0tag:blogger.com,1999:blog-8456525132033459936.post-4026840962749774592010-01-31T20:26:00.008+09:002010-02-13T01:25:41.169+09:00マルチタスク環境におけるWatchdogの設計Watchdogタイマーは基本的にはカウンターでzeroになった時かオーバーフローした時にシステムにリセットを掛けてシステムを再スタートさせるハードウェア部品だ。組込屋さんは、PCプログラマのことをバグがあってもリセットすれば良いと思ってる見たいに偉そうに言うが、実はWatchdogはそれを自動化したものだ。やばい時にはリセットするのは変わりない。
ここでは、どんな使い方をするのかまとめてみる。組込では、RTOSを使う場合と使わない場合があるが面白いのはRTOSを使った場合である。以降はWatchdogタイマーをWDTで表す。
要件(やりたいこと)
OSやタスクの無限ループ、デッドロックの検出をする
低優先度のタスクが動けることのチェックをする
単に動くだけではなく、アプリケーションに応じて健全性チェックをする
設計(つくりかた)
WDTをkickするタスクをモニタータスク(MTasktfujikurahttp://www.blogger.com/profile/05727198324191810209noreply@blogger.com0