Tyzoh.jp

さて、1月に組込みソフトウェア向け開発プロセスガイドのセミナーの、2月に組込みソフトウェア向けプロジェクトマネジメントガイドのセミナーの講師をやりました。その後は独立行政法人ならではの予算編成やらなんやらでドタバタしておりました。
セミナーの内容はエンタープライズで行っている開発プロセス、プロジェクトマネジメントと大きな違いはありません。ただし、メカ、エレキとの並行開発という点が大きな違いです。いままで小規模開発が多かった組込みの世界ではなかなか開発プロセス定義やプロジェクトマネジメントが体系的に行われて居なかったという問題意識からリファレンスガイドを出版し、セミナーをやっているという訳です。

ところで最近、状態遷移表は形式手法か？という議論がありました。エンタープライズの世界では形式手法は1990年代から現場でも議論されており、永遠のテーマかと思ったりもしています。
組込みの世界ではボトムアップに品質保証の取組みは進められており、状態遷移表などはエンタープライズのソフト開発より普及しているかも知れません。
今では状態遷移表をコンパイルするツールもあります。UMLも結構普及しつつあります。
欧州では業界の標準として形式手法の採用が決められていたりして、トップダウンに形式手法の採用が広まりつつあります。日本は状態遷移表大国だったりしますが、どうやって比較して議論すればよいのか。確かに日本では上流工程での形式手法は見劣りするのかも知れません。
でも形式手法というのは形式手法言語だけを指す訳ではなく、形式的に記述されたモデルをプロセスの成果物に変換することでその成果物の妥当性を検証するためにあるのだとすれば、状態遷移表コンパイラもUMLコンパイラも立派に形式手法と威張れる筈です。

活動するフィールドを変えて新しい視点でものを見るというのは刺激になるものです。

年末に自宅のPCもウィルスチェックに掛けました。
1.7GB+40GB+130GBに子ども達が画像とか納めてるので、結構な時間が掛かります。半日ぐらい。
おっと忘れてた、ってボットのチェックもこれまた半日。

元バッチマンの私としては腑に落ちません。
エンドユーザにそんな長時間の処理をさせないように、並行処理とか工夫はできんのか、と。
でも1CPUでI/Oまで面倒見てるPCでは並行処理しても意味無いんですよね。悲しい。ふぅ。
せめてチェックポイント／リスタートで再開できるようにして欲しい...

え？するのか？わたし？

ともあれ、皆様、本年もよろしくお願い致します。
なんだか今年は年賀状も作れなかったので....トホホ。

組込みソフトウェア向け開発プロセスガイド(ESPR)の例題をつくろうと、電気ポットの設計を始めましたが、結構大変です。話題沸騰ポットなんてのもありますが、これだとプロセスの重要性が伝わりにくいのでプロセスごとの成果物の例を作ってます。安全性とか考えるとやけどとか、過熱とか、電気ポットの安全対策って結構考えなくてはなりません。
ちなみに電気ポットの電源ケーブルが磁石で着脱式なのは、引っ掛けても外れるから倒れない、という機能安全の典型例だったりします。

で、話はかわりますが、P901iSのICカードエリアが足りなくなったので903以降の機種を探しに行きました。904には体感ゲームという機能がついています。Wiiみたいなものか？と試したくてD904iを買ってしまいました。
Wiiほどではありませんが、ケータイを振ったり、傾けたりしてゲームができます。きっとそのうちに振ったり傾けたりしたらメールが書けるようになるんでしょう。あるいは酔っ払ってあるいていると警告メールが妻に発信されるとか。ケータイにこんなセンサーつけてどうする。ゲームするぞ。

こんなセンサーが安くできるならポットでもなんでも搭載したくなります。
マウスにつけるとどうなる？楽しそうだぞ。

さて、11月14日〜16日、組込み総合技術展が開催されます。
"Embedded Technology 2007"、略してET2007。"Embedded"という言葉も日常用語になってきましたね。このあいだもIPAで私の愛妻弁当を見て「エンベッディドだねぇ。」「ええべんとうだねぇ。」.....
すいません。

ところで今日はチュートリアルセッションが早速始まり、行って来ました。IPAの活動を紹介する内容だったのでまたどこかでゆっくり書きましょう。明日は坂村教授、八尋課長、田丸氏はじめ、Embeddedでは著名な方々の講演やパネルディスカッションなどがあります。
明日行き損ねた方は15日、16日にもまだまだあります。ちなみに私はIPAのブースで20分のプレゼンをやります。

大規模化し、社会への影響も再認識された組込みですが、様々な立場からの展示・発表があります。みなとみらい線のおかげでアクセスも便利になった横浜パシフィコにどうぞお運び下さい。
http://www.jasa.or.jp/et/

組込みは社会インフラに....だけど...で「当たり前のことをしっかりやって行かなくてはならない」書きましたが、組込みってそんなに当たり前のことができていないのでしょうか。

いえね。最近とみに大規模化してきたしぃ、いままでとは違うしぃ、という話もあるんですが。
それに今まで命に関るような組込みはちゃんと動いましたよね。
自動車の組込みで、組込みソフトがリコールの原因になったのは2006年が初めてだったと記憶しています。
# 11/13/2007訂正：20世紀には年に1件有るか無いかだったのが、2000年〜2003年まで2件〜3件、2004年2005年は9件に。2006年は11件と二桁になりました。＞ソフト不具合の自動車リコール(国土交通省リコール届出)

まず把握しておかなくてはならないのは、組込みソフトウェアは、
・機械(メカ)
・電気(エレキ)
と一緒に開発されるという大きな特徴があります。

先日組込み機器を製作されているメーカーさんを訪問した際も、一番の難点は、メカ、エレキとソフトが別々に開発されつつも同期を取らなくてはならないという点だとおっしゃってました。そりゃそうですよね。既存のH/Wにソフトを作りこむのではなく、H/Wと同時に開発が始まるとなると、メカ屋さんの仕様変更、電気屋さんの仕様変更、ソフトウェアの仕様変更のマネジメントなんてどうすりゃいいのか気が遠くなります。
結局はマイルストーンを置いてすりあわせを行うという基本を忠実にやるしかないのですが。

当たり前のことをしっかりやる、でもその前に複雑な関係者がいて、成果物もメカ・エレキ・ソフトそろい踏みが必要、ということを肝に銘じて置きたいです。
IPA/SECではそろそろ「組込みソフトウェア向け開発プロセスガイド」の第二版が出ます。機能安全やプロジェクトマネジメントも含めたガイドとなっています。是非、活用の際にはメカ・エレキとの共同作業であることも意識してご活用下さい。

先月、組込みが世間がお騒がせしました。
10月12日にSuica、PASUMOの改札機の電源が入らなくなり、首都圏は大混乱しました。10月18日には改札内のSuica、PASUMO端末の電源が入らなくなりました。
ひとつのメーカー製品でした。
職務上知りえた情報は抜きにして、報道を解説すると、次のようなことが起こっていました。

朝、Suica、PASUMO対応端末・改札機はサーバーからデータを受取って機械のフラッシュメモリに書き込みます。Suica、PASUMOも、カードから自動的にチャージするなんて機能もあります。例えば、あるカードは使用禁止とか、使用できない(紛失)定期券などの情報を朝一番にサーバーから受取って機械の中に保存しておく訳です。
なにしろ改札機ってのは次から次へとカードを捌いて行く訳です。1回タッチするだけでも20回以上のやりとりをしています。普段忙しいので、朝、まとめてデータを通信で貰って、自分の機械の中のメモリに書いておくって訳です。

ところが、ある会社製の機械では、85回に5回発生するバグがありました。
1.データ長がある長さを超える
2.フラッシュメモリにブロック単位で書き込むときに余る、データ長が特定のバイト数である。
というときに発生します。

ここからは想像です。
いままでは1.の条件を超えるデータ長を受信することがなかったんでしょうね。PASUMOが始まってから半年以上たって1.の条件を超えるデータ長になったんでしょう。
2.はソースコードを見てみたいです。ま、フラッシュメモリに直接APが書き込むようなプログラミングをしていたら、フラッシュメモリのブロック長を意識して書き込まざるを得ません。だからブロック単位にデータを分ける処理が必要なんですが、そこがバグっていたと。

さらに不思議なのは12日の対応をしたのに、18日に機種の違うもので同じバグが出ているということです。

素朴な疑問ですが、本当に朝だけ通信して書き込むならI/Oをモジュール化して、APではブロックを意識せずに書き込みたいです。もし朝だけじゃないにしても、C言語で言えばマクロ関数でも使って標準化しておけばいいのに。そうすれば18日の再発は防げた筈です。

テストは？どうやって通過したんでしょう？

決してその会社を非難している訳ではありません。
組込みプログラムがこれだけ社会に影響を与える存在になったからこそ、
・テストによる品質担保
・ライブラリ化・標準化による品質担保
・変更管理による再発防止
など、当たり前のことをしっかりやっていかなくてはなりません。

今、IPA/SEC 組込みプロジェクトでは、開発プロセス、プロジェクトマネジメント、コーディング標準化のリファレンスマニュアルを出しています。これからはさらにテストの基準なども取り組んで行きます。組込みなみなさんには是非IPA/SECの成果物を活用して頂き、私たちと一緒に品質の向上に取り組んで行きたい、と感じて頂きたいです。

情報ビッグバンは始まっている -その兆候-のつづきです。

今までは個別部門、個別企業からサービス提供がされてきた。しかしこれからは部門間、企業間連携を前提とした柔軟なサービス提供に変わっていきます。
そしてサービスアーキテクチャが変わり、ITアーキテクチャも変わります。

PDMの例で言えば、製品設計部門、生産設計部門、部品メーカーそれぞれの情報が互いに参照できなければ困るような状態に陥っています。
例えば、部品共通化が進んだために、部品が原因のリコールがあれば、製品への影響はいままでより広くなっています。あるユニットが原因であれば、そのユニットや、類似形状の設計も見直す必要があります。
このためにはマイニング技術といってもテキストマイニングだけでなく、イメージマイニング、3Dモデルマイニング、3Dモデル類似形状検索などの技術が必要となり、メディア横断・統合検索技術が無くてはなりません。
そしてその検索対象は部門を横断し、企業を横断しなくてはならません。そこには適切なセキュリティとアクセシビリティの設定が無くては、企業秘密を守りながら情報共有をすることなど不可能です。

情報共有の例を見てみましょう。
社内の情報共有にせよ、顧客の情報共有にせよ、データ量の増大、質の多様化、連携の複雑化の洗礼を受け、簡単に共有できるものでは無くなっています。
「情報共有」はECM (Enterprise Contents Management)の視点が必要になるでしょう。データをデータとして扱うのではなく、コンテンツの塊として扱うのがECMです。データを情報にし、情報をコンテンツとして扱うためには、データ収集・蓄積・検索・分析の技術として、クローリング、センサーデータ処理、ストリームプロセシング、マルチメディアコンテンツの扱い、タグ付け、SSDB、Indexing、マイニングなどの技術が必要です。また、ビジュアライゼーションの技術として、立体化、動画、地図との連動….などの技術が必要となります。さらに、部門間をまたがるサービス形態を考慮するとSaaS、SOA、仮想化技術も必要になります。
サービス全体を提供するときには、さらにセキュリティ、コンプライアンス、ナレッジマネジメントの面から考えていく必要があります。

ところで、コンシューマは今の検索で満足しているのでしょうか？
ちょうど旬な話題として「感性検索」というものがあります。日経新聞8月20日にも取り上げられていました。
@ITの記事を紹介しましょう。
ニッセン、感性やこだわりで選べるイメージ検索システムを導入に概要の紹介があります。
このシステムを開発したALBERT社のNRはこちら。
ニッセンのオンラインショップで導入 感性やこだわりで選べる、ALBERT のイメージ検索システム「ISS」
画面イメージの説明が分かりやすいですが、ヒールにカーソルを合わせ、「ヒール細め」などの条件で他の商品が表示されるというものです。まだ実際に試していませんし、妻の意見も聞いてませんが、なかなか良さそうです。内部的にはメタデータとしてタグを持っているということなので、tPodを発展させるなどの方策をとれば当社でも適用可能な技術だったかも知れません。

ただ、残念なのはこの技術を提供したのが当社ではなかったということです。
当社の持つ技術と情報ビッグバン時代の要請を突き合わせて見る必要があります。

この間の懐かしい特許出願を機に、個人のホームページを整理してみました。
www.UKON-CLAN.jp
大体2000年頃からの活動の記録を取ってあるんですが、e-LearningはALICという団体がなくなってしまって公開記録も少なくなりました。
全然対外的に公開することがなかった時期もあります。

こうやって振り返ってみると、ブログやSNSが流行る昨今もスタティックなホームページの価値もあるんだなぁ、と思ったりします。

情報ビッグバンは始まっているの続きです。

最近、マルチメディアデータの扱いで何とかならないかと思うことがしばしばあります。例えば90分の会議の会議録を録音データで確認しながら議事録を作ると確実に90分以上かかります。自動認識ソフトを使いたいです。

3連休は娘の文化祭のビデオをPCに取り込みましたが、8分の録画を処理するのに8分間デジビデを回したあと、「ファイルを作成しています。あと16分...」と言われてしまいました。デジタルなんだから8分の録画を合計3分ぐらいで処理したいと思うのは我侭でしょうか。

さて本題です。手近なところをみれば、社内の情報共有で、何度も「xxxのパッケージ知りませんか」という類の投稿がなされています。これは他社含むパッケージに関する情報が整理されずに溢れているからでしょうか？パッケージを適用しようとしたとき、カタログスペックを集めるのは簡単です。しかし、「実際のところどうなの？留意点は？苦労するところは？」ということが知りたいからこそこういう投稿が出てくるのです。前回「コンテキストの塊」という言葉を使いましたが、今のこの例ではパッケージソフトに関する文脈上の情報(コンテキストの塊)が上手くまとめて検索できないことがポイントです。共有したい・欲しい情報の質の変化に対応できていないために、結局情報共有という手段よりKnow Whoに頼っていると見ることもできます。

タイミング良くある業種の担当営業から、お客様の現場力強化のための情報共有についての相談が舞い込んで来ました。上であげた社内の情報共有と同様のきっかけがあると想像できます。

一方、ものづくり大国である日本の先陣を切る製造業の担当営業からもPDM (Product Data Management) の複雑化への対応の相談が来ています。扱うデータの質や量が変化していたり、PDMにかかわる関係者が増え、PDMの情報の扱いが複雑化しているということだと考えます。実際、PDMは単に部品表を管理する訳ではなく、組込みソフトまで管理する必要が出てきているのです。

これからやって来るビッグバンに備えることも必要です。しかしまず、早急に「今既に起きているビッグバン」に対応を行わなくてはならないでしょう。当社のお客様は「今既に起きているビッグバン」に対応しようとしておられます。そのお客様に当社は有効な提案をし、有効なシステム開発が出来るのでしょうか？
アーキテクチャは？必要な技術は？

次回、もっと詳しく見て行くことにします。

懐かしい特許であげたサイトですが、
「目標達成のためのプログラム作成支援方法および作成支援プログラム」
の広告がGoogleのAdSense。これがすごい。

私の名前で検索すると、「右近豊胸クリニック」というのが引っ掛かってくるのですが、その影響でしょうか。
Google検索 「右近豊」
で検索した結果から「目標達成のためのプログラム作成支援方法および作成支援プログラム」へ行くと、やたらと「豊胸」の広告が出てきます。

Tyzohブログから直接行くと、広告が普通です。
すごいぞGoogle。
見事なSenseだ。
それでいいのか。本当にいいのか。右近豊が豊胸なのか。笑うぞ、Google。
いや、Googleに笑われているのか、右近豊 胸クリニック。もとい右近 豊胸クリニック。