セッションF4 組込みソフトウェアのデザインパターン司会：　服部、大山参加者 25名程度（以下、敬称略）服部まず,これまでまとめたデザインパターンについて説明します. 大山ホームページ掲載したものを紹介します. この活動はCESTで2000年からはじめました. もともと私が発案し,服部さんと一緒にまとめました. 組込みソフトウェアのデザインバターンとは組込みソフトウェアには，非組込みソフトウェアみ見られない固有のデザインパターンがいくつも存在する. ->教科書には出てこない.文献では十分に明らかにされていない. これらを明らかにして組込みソフトウェア開発技術者に有用な学習教材を作ることを目的とする. GoFのデザインパターン(参考) 「オブジェクト指向における再利用のためのデザインパターン」をきっかけにブートなった.（非組込みシステム用）目的はオブジェクト指向ソフトウェアを設計する際の経験をデザインパターンとして記録すること. デザインパターンとは,重要でかつ繰り返し現れる設計を，それぞれ名前付けし,説明を加え, 評価したものこれまでの活動とSWESTへの期待これまでの取り組み CESTは三河地域20社程度の企業が参加しており，自動車業者が多いそのため,これまでにないパターンの収集を行いたいと考えている. 設計パターンと実装パターンデザインパターンはこの2つに分けている. 設計パターン設計の骨格・構造に関わる自称を扱うパターン比較的抽象度の高いもの実装パターン設計自称を特定した実例パターンより具体的な設計 Tips One Point 設計パターン大山さんがまとめたものタスクスケジューリングハーモニックタスクパターンシングルバッファリングパターンダブルバッファリングパターンリングバッファパターン状態遷移システムリターンリターンパターン大域脱出パターン .... リターンリターンパターンエラー処理に関するパターン関数を呼び出すごとに正常終了が，異常終了がをテストする. オーソドックなパターンハーモニックタスクパターン目的倍数周期のリアルタイムタスクにより，安全かつ効率のよい組込みシステムを実現するリアルタイムタスクに100%のCPUを割付可能デットラインに対して十分なマージンを持つことが可能すべてのタスクについて,あるタスクの周期が，より短い周期のタスクの倍数の周期となっている． t1max/T1 + t2max/T2 <= 1 実装のパターンウオッチドックに関する実装パターンエンディ案変換実装パターン EEPROMに関する実装パターン NOPの挿入実装パターン PWMに関する実装パターンＲＡＭバンクに関する実装パターン SFRリフレッシュに関する実装パターンクロック切り替えに関する実装パターンスタートアップに関する実装パターンスタックに関する実装パターンタイマ・カウンタに関する実装パターンメモリチェックに関する実装パターン関数パラメータに受け渡し固定小数点演算に関する実装パターン省電力に関する実装パターン排他制御に関する実装パターンエンディアン変換エンディアンの異なるCPU間でのデータ変換を行う場合，データのご認識を回避する実装の方法実装アプリケーション全体において，処理対象のエンディアンを統一する変換には処理計に依存しない方法タイマー・カウンタ目的処理事象が時間ベースの場合はタイマ処理事象が回数ベースの場合はカウンタ実装インクリメント型デクリメント型タイマの場合，使用変数サイズを小さくしたいために基準時間を変更する場合があり，その場合は公差を考慮する必要がある．省電力に関する実装パターン現在頭を悩ませている（まとまっていない）組込みシステムはバッテリーを使う製品が最近多いシステムの規模が小さくOSを使っていない場合が多い，そのため,力技でスリープモードしている．これをOSを使って矛盾せずに実現するにはどうすればいいか．提案していただいたパターン二上さんのパターン上流設計のパターン（難しい）ある人が経験したものは他の人も経験する ->パターン幅広く考えればいいかなと考えているアナログデバイス:堀江 SWESTに参加して少々場違いのような気がした．ソフトウェアパイプラインパターン(DSP) 目的・同期繰り返し処理においてDSP/VLIWの並列命令を最大限に利用する日本におけるDSP恐怖症を払拭したい．ハードウェアのパイプラインと比較してソフトウェアパイプラインと呼ばれる．命令セットをにらんで並列に実行可能な命令を見つけるのが一番困難実装 Excelを用意する．ループを展開し，ループボディーをずらして重ねたあと，再度ループ化する -ずらす量は最初はあてずっぽうにする． -ずらして横に並べたもので1命令で実行できるものを見つける手作業の場合，スプレッドシートを使うと簡単にできるループボディーをピッチ，並列度を段数に見立てるループ内のレジスタ変数の寿命はピッチ以下大山場違いとおっしゃられましたが．堀江信号処理の話は出てこなかった．大山私もNC屋なので場違いと思っているが．いろいろな業種のパターンが集まるのがいいと思う. 堀江ループ・アンロール・パターン目的・同期ループから命令・レジスタ依存性能によるストールを取り除くことで高速を図る．実装の方法 N回ループをK回単位に展開してN/K回のループにする K個のループボディーの命令をインターリーブ配置するアドレスレジスタ，更新が繰り返しあたり1回であり，かつ自動更新モードの時のみ共有できる．最近RISCのレジスタ数が増えているのは，このような処理を実現するためである．大山このようなものはかならず使うものなのでしょうか. ほりえ TIの6000やアナデバのタイガーシャークではこのようなものを使う．大山このようなものをパターンを出してもらうと，分野が違ってもある程度の知識を得られるのでいいなとおもう. 服部市川先生も最内周ループを最適化するといいといっていた．穴田市川先生は演算処理の効率を上げることを専門にしているので，関連する．音響処理の専用のDSPを使っている. 勉強会で少し勉強した. DSPは専用の演算器をもっているのでそれの利用率を上げることが重要最近のDSPはどうなんですか. 堀江深いパイプラインが一般化している. 昔は積和演算を1命令で実行しなければならないという命題があったので3段ぐらいでした．最近10段から15段あるその代わり600Mhzから700Mhzの性能となっているその代わりにストールが発生する． SIMD化が進んでいる． C言語でDSPのプログラムを最適化をするということは不可能だと思っている. 最適化したい部分はアセンブラで書くべきものである. 大山アセンブラで書くべきだから，このようなものがデザインパターンとして必要になるアウトオブオーダー，スーパスケーラはどうなんでしょうか. 堀江消費電力に対する要求が高いので，アウトオブオーダー，スーパスケーラ等は許されない. STARC:はきわら小メモリヒープのフラグメント防止 : 皆さんどうされているのか情報収集をしたい目的ガーベージコレクションのない単純なメモリ管理においてヒープメモリのフラグメンテーションを回避したい．実現の方法殆ど開放しない領域はstatic配列とする同じ時期に開放できるものは一緒に確保サイズの大きいものと小さいものを別領域から確保　(例えば，小さいものはヒープの先頭から，多きものは終端から確保する) 大山うちのNC装置（リアルタイム系）ではヒープを使ってはいけないという鉄則になっているどういった用途で使っているのでしょうか. はぎわら JavaのVMを作っていて，客から1ヶ月連続稼動させたらフラグメンテーションが大きくなりすぎて止まったとクレームがでた． Javaはソフトウェアをダウンロードして実行するため，staticな確保は不可能一部ネイティブなコードがあるため，それが原因となる． A 私はサイズに大きなものと小さなものを別領域から確保を実装しました. ネイティブの方の挙動が分かれば,ネイティブとJavaのヒープを別に用意すると影響が分離できる. はぎわら実際にヒープを分けることによる問題はなかったのでしょうか. A 最大数が予想つくケースであったので問題なかった. 穴田まったくそのとうりだと思う.組込みは長時間動作するため,この問題は重要．サイズに大きなものと小さなものを別領域から確保を実装を進めて, 完全にメモリの確保と開放を全て把握して最大数を抑える実装をしました. Javaでは把握は難しいと思うのでその処理事態をJavaで実現するのに向いていないんじゃないでしょうか. ほりえ最近C++を使うのでヒープを気にしている. クヌースのアートオブコンピュータプログラムという本がありお勧めです. ヒープの割付サイズをブロック化することが重要である 16の倍数として渡す. フラグエントされたところから再割り当てする方法もいい方法が書いている. Macでやっていた２重ポインタとスライド大山私自体GCを使う言語を作ったので興味がある. ヒープを使っている人はどのぐらいおられるでしょうか． ->5名 B 私自身は好きでないですが,ライブラリが使い互換性のため使っている. なぜ使っているのかももう分かっていない. 大山どうやって動作を保障しているのでしょうか. B 過去の資産に関してはどうか分からない. これまでの実績で使っている. C 使ってはいますが,昔からの手法で，何処からどのようなデータが来るか分からないものを書く場合に使う. 不具合があった場合に原因がつかめにくにくくなるという問題は感じる大山私は使ったことがないですが,パターンになっていると認識が簡単にできていい. 穴田ヒープ,マーロックは単純に使ってはいけないわけではない. 実績等はありますし,組込みの場合中身がみえて自分が安心できれば malloc を使うものもいいんではないでしょうか. 大山小メモリのデザインパターンという本があるので有用なのではないでしょうか．動いていたコードには手を出すなも重要なパターンだと思います C さっきと逆の話で,ヒープを使っていけないという会社はあるか聞きたいのですが. -> 9名 C 使っていない理由は鈴木 malloc自身がライブライから外れている. 大山穴田さんはなぜ使わないのですが. 穴田明文化されていないませんが,師匠が使ってはいけないと言ったから使っていません. 大山長時間動作の場合は不安, 鈴木テストができないからですね. ヒープの問題はmallocが悪いわけではない. いろんなアプリが使われる場合は全てのケースを網羅するのは不可能. だから使わない. 大山パターンをあげてもらおうと思っていたのですが,メモリーの話しで盛り上がりました. 森実装の最下層に近いパターンで開発プロセスのパターン JavaでUIのモデルでモデルビューコントロールがあるその発展系でMUIモデルがある. これはUＩはとモデルを完全に分離する. 組込みに適応すると,HWの納期は遅れるそのため,マルチタスク環境を要してモデルのみ作成し，HWが完成してからUIをつけて動かす. 大山これをしているひと ->あまりいない実際MVCを使うことをあまりない. うちは UIのレイヤー NC-API ＮＣモデルと完全に分離している. NC-APIの部分をネットワークにするといったことをしている. レイヤーに分けるというのも一つのパターンといえる. 二上鹿威しのパターン要求分析から実装コンピュータはださない.客と水と亭主この要求をのこしたままメカトロニクスとしてのI/Oを入れる. ２次元のまま機能を追加する. 大山いつもやくにたつのでしょうか. 二上小規模で割込みや同期処理が自由に使え,プロセッサが十分に早ければこれで十分に設計できる. リアルタイム性が厳しくなってくるとこのパターンだけでは難しくなる. 大山ここらへんはまとまっていまか二上セサミでこれからしていく大山パターンの話をすると人事に受け取り方が異なるというのがわかりました.本来ならパターンを出してもらいたかったのですが，幾つかできたのでよかったかなと思います. 服部随時募集していますので，MLに流していただければと思います.