自動車業界では、MATLAB/Simulinkをベースとしたモデルベース開発が有望視されています。言うと、適用方法によってはそれなりに工数削減や品質向上が出来ると言う事が実証されてきたからです。一方ではモデルベース開発によって逆に工数が増加してしまうケースもあり、まだまだ課題が山積みです。これは、ユーザー様にとっては課題が山積みと言えますが、私にとっては仕事のネタが山積みとも言えます。このブログでは、そういったモデルベース開発に関わっていく中で思った事について書いていきます。更新日は月曜日+気が向いた日です。yositakeTags:弊社は、自動車業界向けに開発支援ツールを作成させていただいています。これまでは、特別規制などなくやってこられましたが、今後はそうもいかなさそうです。いうのも、ISO26262が法律で義務化されそうな見通しだからです。複数のお客様から、ISO26262が義務化されると開発ツールにも規制が入るとの情報をいただいており、大変に気をもんでいました。「いったい、ツールベンダーの立場からISO26262とどう関わっていけばいいのでしょうか?」これが今回のテーマです。したものか・・・と思っていた所に、ESEC2010にて機能安全セミナーが開催されるとの事で、喜んで行ってきました。セミナー超ざっくり詳しい内容を全部書くと怒られそうなので、それは講演テキスト要録というものに譲ります。(組み込みシステム開発技術展の専門セミナー全部ふくんで¥80,000だそうです)ここでは、怒られそうにないくらいに、超いいかげんにまとめてみます。(あんまり信用しないでくださいね。)まず、ISO26262では安全に関わるいろんな事象をランク分けします。ヤバさでA~Dにランク分けします。Dの超ヤバイ事象に関しては、こうこうこんな手厚さで開発しなさいね。Cならこれくらい、Bならこれくらい、Aならこれくらい頑張りましょうね、という事が延々と書いてあるそうです。セミナーでは、これらの詳しい話を色々とお聞かせいただきました。Dの事象についてものすごく頑張ってソフトを作りました。ところが、使ってるツールがヘボくて正しい結果が得られませんでした。結果として事故が起きちゃいました。こんなことになると何をやっているのか分かりません。ツールそのものについてもキチンとしたものを使う必要があります。ツールベンダーからすれば、「うちの製品はキチンとしてますよー」という事を、何らかの形で示さないといけないという事です。ツールベンダーはどうしたものかな?セミナーの内容はほぼ自動車メーカーさん、部品メーカーさん目線のものでした。そこで、講師の先生に、迷惑を承知で突撃してきました。「あのぅ、私、実はツールベンダーなんですけれども。先生は、イヤな顔ひとつせず色々と教えてくださいました。まとめますと、ISO26262には、「認証」と「認定」がある。「認証」は第三者機関に見てもらう必要があるが、「認定」は自分で宣言してもいい(オレオレ認定書?)ツールに関しては「認定」レベルでもよいオレオレ認定書を作るには、やはりそれなりの根拠は必要。ツール自体がISO26262-6(ソフトウェア)に従って作られている、というのも根拠になりうるかもとのことでした。!注意:上記はあくまで私(吉武)の解釈です。間違っている点があれば、それは100%私の理解不足が原因です。ISO26262導入してみますもう既に、ISO26262のドラフトがネットで購入できるようになっています。そこで、ISO26262-6(ドラフト)を購入して、開発ツールプロセスに組み入れられないかやってみる事にします。考えてもムリという事になれば、業種替えも視野に入れないといけなさそうです。それにしても、まじめにISO26262を導入するとなると開発支援ツールを作るにもものすごい追加工数が必要になります。22:28吉武様ひと月ほど前に静岡からお伺いしました者です.その節は有難うございました.ISO26262について,かつての仕事仲間と話してみました.OEMさんの方に動きが出てきているようです.一方,この手のモノは本記事にも書かれていますように開発者(コードに触れる人)に負担を強いるものです.でも主導するのは,コードなど今ではほとんど触る立場にない人だと想像します.このギャップが,今までの経験では追加工数に対して実際の効果が上がらないまま,なんとなく進んで行ってしまう原因ではないか,というような意見に一致しました.ただでさえ納期に追われながらの作業に,形式としてのドキュメントを整備する時間が加わり肝心のソフトの品質自身は低下する方向へのベクトルが加わってしまう,と言った構図です.今日たまたま目にした「中日春秋(中日新聞コラム)」に次の記述がありましたので引用します.「<世間は活(い)きて居る。勝海舟の言いたかった事からは飛躍しますが,開発プロセスという理屈を持ち出す側として自戒しなければと考えた次第です.ただ少し救われたのは同コラムの末尾に「▼ただ、法理は法理である。硬直的ではいけないが、「世間」が強すぎて「理屈」が引っ込むのも困る。どっちも<活きて居る>であってほしい。01:23先月は、貴重なお話を色々とありがとうございました。コメントありがとうございます。開発者とプロセスを主導する人とに開きがあるとのご指摘は、今まで考えたことがありませんでした。言われてみると、確かにそうかも分かりません。「ただでさえ納期に追われながらの作業に・・・」というお話は、実はCMMについて聞いたことがあります。欧州のとあるOEMさんは部品メーカーさんにCMMレベル3を要求しているのですが、それに対応するための追加工数がものすごくキツイ...とこぼされていました。26262-6の中身をざっくり見てみますと、少し面白いことに気が付きました。26262-6には「いかに高品質の開発を行うか?」のメソドロジーが記述されている(と思われる)事です。Aならウォークスルーをしましょう、なんていう記述があります。細かいところでは、たとえばコーディングガイドラインとしてスタイルガイドを使用したり、変数の命名規則を用意したりしましょう、なんていう記述もあります。エンジニア様がおっしゃるように、ツールによって追加工数を軽減する事ができる部分が、それなりにありそうな気がします。26262を読み込んだり、色々な人に教えていただいたりして、少しずつ勉強していくつもりです。お会いした際には、色々とご意見をいただければ幸いです。15:46吉武様1年ほど前にお尋ねしました。MATLAB/SimulinkのRTWSを調査していて、偶然御社のHPを拝見しました。ご病気だとのことで、心配になりました。静養して頂きたいと思います。今、電力消費のシミュレーションをMATLAB/Simulinkで開発しています。自動車関連とはちがいますが、近似式を作成してシミュレーションなどをおこなっています。はやくお元気になられますよう祈っています。21:16ご無沙汰しております。病気の方は、お陰さまで完治いたしました。お気づかい有難うございます。電力消費のシミュレーションといいますと、プラグインハイブリッドや太陽光発電等をにらんだ住宅モデルでしょうか?それとも、もっと全然別の物でしょうか。何にせよ、ご活躍のご様子で何よりです。一緒にお仕事をさせていただく機会があればと思います。コメントを投稿して頂くには、JavascriptとCookieを有効にしていただく必要がございます。