ネタ帳

今後、ブログに書いてみたいネタの一覧です。

もしもほかに面白いネタがありましたら、教えて頂けると嬉しいです。

HILS関連

正直、これからの時代HILSってどうなのかなぁ・・・という懐疑的な気持ちもあります。しかし、無くなる事は無いと思いますので、いろいろと書いて見たいと思います。

• 「FreeHILS」
  FreeHILSを完成させて、Scicoslab、Simulinkのどちらからもモデリング出来る事を示します
• 「FreeHILSによる、HILSシステム構築例」
  FreeHILSを使って、とあるシステムをモデル化し、HILSによる試験を行います。流れとしては、ECUの「テスト設計」を行ったあとで、実機による試験、HILSによる試験、と別々に行います。そして、実機とHILSそれぞれの長所、短所についてまとめてみます。
• Scicoslab上でModelicaライブラリをどう使えばいいのか？
• 超入門シリーズ： なんちゃって制御理論入門（古典、現代）
• 超入門シリーズ： なんちゃってシステム同定入門
• Comediドライバの使い方、書き方
• ２種類のHILS、検査装置、実機
  ガチのHILSと、むしろSimulink=Labviewみたく使っているHILSモドキ。CやLabviewで作る検査装置に、実機。これら４種類を、様々な評価軸の上にならべてみて、相互比較してみます。

SILS、PILS関連

個人的には、SILSこそが品質向上の最重要ポイントだと感じています。

• 「何か制御システムを、モデルベースで作成」
  モデルを作成し、SILSでみっちりテストして不具合を極力摘出します。それから自動コード生成してマイコン上で走らせます。走らせたものは、FreeHILSによる試験を行います。SILS上で「ロジック誤り」を極力排除する事が、どれだけラク＆効果的であるのかが、見てもらえると思います
• 「制御モデルとレガシーCの融合：私の考える現実解」
  最近、レガシーのCコードをすべてSimulinkに移植しようという動きがあります。しかし、個人的にはこれには反対で、もっといいやり方があると思っています。そこで、上記ネタでやった「フルSimulinkによる制御モデル開発」を、私の考えるもっと現実的な手法に置き換えてやってみます。そうして両者を比較し、それぞれの長所、短所についてまとめます。予想では、フルSimulinkでやって自動コード生成した場合よりも、かなり効率的なコードが吐け、しかもモデリング時間も短縮できるはずです。
• 「どう書く？ネタ」
  C言語に色々なアルゴリズム実装パターンがあるように、Simulinkにもいくつかのパターンがあります。それらをどうやって書けばいいの？というのを、SimulinkとScicosLabと並べつつ列挙してみると面白そうです。

モデリングツール(Simulink、ScicosLab）

モデリングツールの使い方いろいろ

• S-Functionの書き方（離散、連続）
• ScicosLabへのCコードの埋め込み方法
• ScicosLabのカスタマイズ方法（ツールを埋め込んだりする方法）
• レガシーコードツールの使い方
• Embedded MATLABで遊ぶ
• Scicos-HDLを使ってみる
• 超入門シリーズ： Scicoslab入門。操作方法、モデリングの考え方、自動コード生成の方法と生成コードの構造、など。
• 超入門シリーズ： Modelica言語入門
• 「（もしもお金が余って余って仕方がなければ）MapleSim入門」
  このMapleSimは個人的にすごく気になっている製品です。しかし小遣いで買うにはちょっと高いので躊躇しています。ダレか貸してくれないかなぁ！
• 「（もしもお金が余って余って余って余って仕方がなければ）SimScape入門」
  このSimScapeも個人的に気になっている製品です。しかし小遣いで買うには（以下略
• 「Simulinkのソルバの説明」
  odeって何？と、客先でたまに質問されます。がっちり説明すると数式だらけになるし、ざっくり説明するとあまり意味の無い説明になるし・・・バランスが難しいです。
• 「知っ得 Tips」
  SimulinkやScicoslabでモデルを作る際、知っておくと便利なショートカットキーや、操作方法を解説します。

規格関連

• ISO-26262を読み解く（機能安全）
• AUTOSARとSimulink。AUTOSARは今のところOSに相当する部分が重すぎて実用には難ありといったところです。しかし、どうやらこの部分をハードウェア化して、SWコンポーネントの部分だけに集中できるようなマイコンが出てくるとの事。しかもお値段は従来と同等で・・・（ほんとにできるのか？）こういうチップが出てきたら、かなり面白い事になると思います。

ソフトウェア制作

• 「FogBUGZ活用方法」
  FogBUGZは個人的に気に入っているツールの１つです。うまく利用すると、開発時のモチベーションをぐぐっと上げる事が出来て、とても開発がはかどります。
• 「関心の分離方法」
  ソフトウェア開発手法として、○○指向というのが色々と流行っています。それらとは並行して、「関心の分離」を行う事がソフトウェアではものすごく重要なように感じます。そこで、どうやったらうまく関心の分離が行えるのか、個人的に考えて実行している方法についてご紹介します。
• 「自動生成テストパターンの使いどころ」
  モデルベース業界では、テストパターンの自動生成やら、論理的に仕様との合致性をチェックするツールやらが話題になっています。どうもバラ色の話に見えるらしいのですが、決して何でも解決できる魔法のツールではありません。実は、こういった系統のツールには使いどころというものがあって、それを外さなければとても便利なツールだと考えています。
  • 時間を含む仕様（○秒後にXXせよ）は、検証にすごく時間がかかるため適用しにくいという話を聞きます。それももちろんそうなのでしょうが、そもそもそれ以前の問題なんじゃないかと思います。時間０～１０００で検証したとしても、時間＝１００１で不具合が起きないとは限りません。それだと、検証した意味がなくなってしまいます。かといって無限時間計算するわけにはいきません。
  • 検証対象が仕様モデルである、というのが問題な気がします。モデルに含まれる状態変数をすべて固定小数点にしてしまえば、モデルをFSM（有限状態マシン）とみなせます。そうすれば、いついかなる時でも必ず与えられた仕様を満たす、という事を理論的には証明可能なはずです。状態数が天文学的数値になるでしょうが気にしない！一家に一台スパコンを用意して、それらを並列に動かせばいいのです。完璧な計画！
• 「ソフトウェア開発プロセスの現場導入」
  プロセスを導入する意図は、品質向上であったり工期短縮であったりします。そのために色々な手法が提唱されていますが、なかなか現場に浸透させるのが大変です。一番のポイントはやっぱり「人間、一度にたくさんの事は覚えられない」という所から来ている気がします。それをどう乗り越えていったらいいのかなぁ？という、ごくごく個人的な洞察。
• 「設計図は書く？書かない？」
  設計図はみっちり書くべきだという人と、どうせ書いてもムダだからいらないという人がいます。私は、こういうのは案件ごとにケースバイケースで対応したらいいじゃん？と思っています。ですが、そもそもケースバイケースでどう対応したらいいの？という所が難しいようです。いろんな考え方があると思うのですが、私はこうやって対応しているよ、というところをご紹介します。
• 「ソフトウェア開発工期の見積もり」
  すべての案件の開発工期を、正確に見積もるのは不可能です。 そこで私がお仕事をいただく際は、平均的にこれくらいで出来るかな？という所でお見積もりを差し上げるようにしています。見積もりより早く終わってしまう事もありますし、遅くなってしまう事もあります。早く終わったからといって値引きはしませんし、遅くなったからといって追加請求もしません。個々の案件で１００％の見積もりは出来ませんが、平均的にみるとなかなか良い見積もりが出来ているように思います。本当は、時間がかかったらかかっただけ請求するのが正確なやりかただと思うのですが、お客様は嫌がられます。私としても、お客様が嫌がられるような事はしたくありません。そんなわけで、平均的な見積もりを行う事になります。これを、FogBugzとからめてやると、なかなか面白い事になります。そんなお話。

モデルベース関連ツールのアイデア

自社製品で作るつもりは無いのだけれど、受託開発としてなら作っても良いかなというアイデア。全部を書くと仕様書みたくなってしまうので、根本的なアイデアのみご紹介します。

• レガシーCコードをモデルに埋め込むツール
  現在でも似たようなツールはいくつかありますが、色々と問題点があるように思います。どんな問題があって、どうクリアするべきか？を書いてみます。
• UMLとSimulinkモデルの変換ツール・・・よりももっと良い物
  UMLモデルって、ソフトウェアの振る舞いを記述するのに特化しています。「ソフトウェアの振る舞い」というのは、手続き型言語のように、さいしょにこれをやって、次にあれをやって・・・という原理で動作するもの、という意味です。一方、Simulinkモデルというのはソフトというよりもハードウェアの回路図を書くのに似ています。それはつまり、Simulinkモデルの各部分が基本的に並列に動作する、という意味です。だから、HDL CoderなんかでストンとHDLに変換できるんです。（もちろんこれは概念上の話で、PC上で動作させる際には結局、逐次実行せざるを得ません。HDLに落とせば、当然並列に走ります。）
  UMLのような逐次実行から、ハードウェアのような並列実行の世界に持ち込むにはどうすればいいか？というと、動作合成っていう処理をします。CatapultとかCynthesizerとかツールはいろいろあるんですが、なかなか「これさえ買えば幸せになれる！」というような感じでもないようです。（意見には個人差があります！！！訴えないでね。）
  まぁもっとも、Stateflow使えば、この手の処理を簡単に書けたりします。JMAABなんかは、Stateflowに逃げるという手法を推奨してますね。
  それで思うのは、UMLとSimulinkって関連づけてもあんまりうれしくなくない？っていう事です。それくらいなら、Simulink単体で再構造化できるようなツールをちょいちょいと書いてやったほうが、よっぽど嬉しい気がします。要するに、きちんと構造化できりゃそれでいいんですから。じゃあどうやるかというと、だいたい「サブシステムを移動する」＝どこかにまとめる、どこかから引っ張りだす、という操作くらいしか必要ないわけで、UMLっぽく全体を把握できるダイアグラムを表示しつつ、これを簡単にできるようなツールつくったら、Simulinkモデルの整理がすっごく楽になると思います。「Simulinkモデルの振る舞いを一切かえないで、なし崩し的にリファクタリングできる」ってところがミソですね。

雑多なアイデア

• なぜブログなんて書くのか？何を書くのか？
  とりあえず生きてますよ？というpingくらいにしかならない気がします。あと、一人でも読んでいただける方が居るかも・・・と思うと、ちょっとは真面目に下調べします。それで自分自身の勉強になる、というくらいでしょうか。
  あと、「知識の内容」を書くだけじゃなく、「わざわざ時間を掛けて記事を読んだら、何かいい事あるの？」という疑問に最初に答えておかないといけない気がします。これはもう、ブログを書くことでしか出来ない訓練かと思います。