********************************************************************** セッションS-5b テーマ：急変しつつあるプログラム言語/モデリングMBDの近況と変遷講師：鈴村　延保氏 (アイシン・コムクルーズ株式会社) 日時：201５/8/29 参加人数：約25名（終了時） ********************************************************************** 新しいことを理解するとき、トップダウンとボトムアップの2つの方法があるボトムアップ…理解し、納得を繰り返して積み上げる。疑いから始まるトップダウン…大きく抽象的なものをひとまず納得して、そこから理解する。信じることから始まる本日はトップダウンで考えてみよう弘法大師が見つけた願いが叶う3つの方法 1,願いを心で強く念じる 2,願いを言葉にして唱える 3,体を動かし、行動する空海メソッドと呼び、ソフトウェア開発にも適用してみようこの場でも空海メソッドの実現として、考えて、手を挙げて質問してみよう MatlabによるMBDが車載組込み開発の本流になっている MBDは機能安全の流れを織り込んで、simulink、UML、sysMLを適材適所で活用している。実務で応用が進んだ結果、昨年は不足点、改良点が顕在化された。その結果、GSN、D-CASE、SCN(SCDL)、safeMLといった新しいキーワードが広がっている。フィーチャー図、DSM図、状態遷移表、マインドマップなどとの併用の必要性も言われ続けている。モデリングというのはプラグラム言語とペアになっている。 Apple社のSwift言語は発表以来1年で前例のない勢いでデファクト言語に駆け上がろうとしている。一方でロボット開発。 pepperはC++とpythonで開発。組込みでmrubyも広がっている。これらの動きはインターネットの時代、深く潜行して突然浮かび上がる。このような動きはサイレントパラダイムシフトと呼ばれる。特に英語圏で先行し、非英語圏は置いて行かれる。本セッションでは、 ①MDBの根底は何か？ ②機能安全が定着してきて、何に困って、今何に取り組まれているのか？ ③何が停滞し、何がブレークスルーしているのか？を確認していく以下　今日の進め方をもうすこし詳細にまず説明しよう・現状認識と課題背景シリコン革命とそれに伴ったパラダイムシフト・MBDの根底ソフトウェアの大規模化、複雑化に対応するために、開発の上流シフトが必要上流が入ってくると、アジャイルと言った言葉とも関係してくる。さらに、リーンプログラミング、摺合わせ、プロトタイピングも関係・機能安全で何に困って何が取り組まれているかシステム的な安全には、安全分析、ハザード分析（ISO26262）などがあるどれくらい分析をするかは書いていない。ある程度の粒度が欲しい仕様も設計もセミフォーマルモデリングを使うといいということで、UML、SysMLが使われている。しかし、どこまでどんなふうに使っていいのかガイドラインがない安全コンセプトの書き方などが規格に書いてないセーフティケースのまとめ方も規格に書いてない・何が停滞し、何がブレークスルーしているのか？・最後にじゃあそういった現状で明日からどうするかを考えていこう以上のように話していきますが、ちょっと最初に、全体言いたいことを補足するとパラダイムシフトというのは技術が変わったから起きるのではなく、せざるを得ないから起きている上流へシフトしているが、それはヘテロジニアス、ハイブリッドである現場で使っているC言語には致命的な欠陥があるオブジェクト指向は反省期へ。さらに、アーキテクチャ指向へ UML、SysMLは10年変わっていない、古いシステムプログラミングとアプリケーションプログラミングをひとまとめにしたフルスタックプログラミングプロトタイピング機能安全。ISO15504は設計の下流をターゲットにしている。それより上流はどうやるのか仕様書有りきだが、仕様書を作るための様々な分析が必要モデルベースの仕様書を作るために、ヘテロジニアスを頭に入れよう Ruby、mrubyとC言語とMatlab/Simulinkの比較ではまず現状認識と課題背景開発が大きくなると、どんどん非会話的になっている動かしてみるということができにくくなるソフトだけあっても検証できない大規模化は加速していくその根底にはシリコン革命がある身近なところではスマホは30年で100万倍性能が向上している車1台で3~5ギガバイトのソフトになる車はメカから、メカトロ、ソフト指向へ効率的で高信頼な開発手法が求められる社会全体が、ソフトウェア依存に年々進んでおり、ソフト品質へのリスクが高まっている。対応して年々ソフト品質プロセス要求が高度になっている同じやり方では通じないパラダイムシフトはいきなり浮上してくる機能安全モデルベース開発（MBD) システムズ・エンジニアリング（MBSE) 3つのキーワード一区切り ①MBDの根底、プログラム言語の根底とは？プロトタイピング、リファインメント、実装の流れで開発が行われるすべてをC言語で行うのか？プロトタイピングで求められるものは？会話型、早いフィードバック、ヴィジュアライズプロトタイピングはCでやらなくても問題ないフルスタックという言葉が最近使われるアプリケーション、ミドルウェア、OSなどの層があるが、層によって適する言語が違うのでは？ Cなどはシステム周りの下層に向いてる。 Rubyなどはアプリケーション周りの上層に向いている。全体をフルスタックと呼ぶ Cは40年前の言語しかし、替えの言語がない新たな流れ Swift, Ruby/Python… MBD(モデルベース設計)の発展。 30年前と今では仕様書の量がとても増加しているそれを30年前と同じCで実装するのか Cはコントロールフロー表現以外は苦手欠点を補うためにいろいろな取り組みが行われているなぜMatlab/Simulinkが流行っているか→プロトタイピングが得意だから Rubyもプロトタイピングが得意 Cは苦手 Cは部品化が意外と苦手？関数は制御フローを簡単にするためで、部品化ではない Control Flow中心の応用時代から、Data Flowの重要性比重が高まっているのが時代の流れ。カプセル化でいうと、Cではヘッダファイルどうするのか（階層のどこに置くか）といった問題がある問題があるC言語を使う上でどうするか・Cには欠陥があることきちんと把握する・スタイルガイドとガイドチエッカーを利用する・静的解析ツールを利用する・設計にはモデリングを利用する UMLは2.0以上またはsysMLを利用しましょう、さらに要件周辺でDSM,GSN,D-Case. ツールで補完しましょう DSMとは、 Dependency Structure Matrixの略であり、繰り返しやフィードバックが多い開発プロセスの結果としてのソースコードの階層化状況をわかりやすく表現するために開発されたモデリングにおいて状態遷移図を用いるが、漏れがいっぱいあるだから状態遷移表で確認するそれをだれが確認するか誰かが必ずやる必要がある安全分析も仕様書に盛り込む必要があるこれも誰がやるか誰がやっているかを意識すると良い派生開発、プロダクトライン開発ではフィーチャ図を使おう sysMLに良いテンプレートが必要一区切り Swift言語・Ruby,Rust(Firefox財団）を意識している・REPLとPlaygroundsがキーワード・RuPyデイレクションがサイレントパラダイムシフトの方向 REPL（Read Eval Print Loop）とPlaygrounds (道場)はプロトタイピングのための環境 REPL…コマンドを入れるとインタラクティブに実行できる Playgrounds…動作をグラフィカルに表現できる REPL、Playgroundsができる言語は少ない Matlab/SimulinkはできるがUMLではできていないいろんな言語がRuPy方向へ変わっている自然、簡潔、高級(oo+fo)、会話的=読みやすい=コミュニティに好まれる⇒コミュニティ指向のパラダイムシフト方向 100年単位で見ると天才一人が時代を変えた→天才が集まった会社（研究所）が時代を変えた→コミュニテイしか、時代を変えられない（現在）この認識では欧州ルクセンブルグ宣言が有名世の中はオープンイノベーションの時代コミュニティ指向になっている欧州ＥＵが統合前にこの認識を共有して、先行している時代認識シリコン革命→ネットワーク革命→コミュニティ指向ソフトウェアではオブジェクト指向→アーキテクチャ指向→コミュニティ指向？ RuPy Directionがあるよ今求められていること呪文のような記述は本当にいるのか、コードの読みやすさ、考えやすさが大切ヘテロジニアスとハイブリッドとは UMLはソフトウェア開発のツールでメカの部分に弱い Matlab/Simulinkはソフトも電気回路もメカ設計もできる、これは実はヘテロジニアスでハイブリッド UMLもヘテロジニアス、ハイブリッドな方向へすこし進化している（UML2.0、sysML）ソフト、メカ、ハードの隙間は見えにくく、ギャップをなくすことが必要 ⇒『システム設計』『アーキテクチャ設計』現在様々な取り組みが行われている上流工程における欠陥率上流工程で欠陥が混入しているのに、その工程で見つかっていない欠陥が見つかるのが最後の段階やり直し、作り直しが大きい作ったらすぐにレビューする、欠陥を除去する必要がある仕様書はなかなか完成していない本当に完全なのか疑うべき仕様書は開発過程で出来上がっていくものかもしれないだから、MBSEを使っていきましょう Matlabはすぐにシミュレーションできるので欠陥を素早く見つけることができ、その都度仕様を更新していける仕様書は開発過程で完成されるべきものなのか、エゴではないか？大丈夫、それが本来のやり方 MBDとMDDの違い MBD…Matlab/Simulink MDD…UML 仕様書はなかなか完成していない仕様書だけでは検証できない？例：仕様書通りのソフトウェアであるが、悪路を走ったら、センサーの誤ダイアグを検出した。どのくらい悪路を想定しているか、どこかに記載していなければ、検証できない。（根拠）悪路に関する記述を、仕様書にいれるのか、セットで背景として要求書に入れるのか（このあたりが、GSN,D-CASEの出番） UMLの欠点 2.0になってUMLは10年間変わっていない sysMLも10年間変わっていない様々な欠点、弱みがあるので、MATLAB/Simulinkの応用が拡大している。 DSMモデリングや依存性表現モデリングも必要で拡大。自動車は複雑な制御を行っているヘテロジニアス、ハイブリッドになればなるほど難しくなっていく E&E&Eへの変化 Software Engineering & Architecture Engineering & Systems Engineering ソフトウェア工学だけに取り組んでいたのでは古い I&I&Iへの変化 ISO16949 & ISO15504 & ISO26262 P&P&Pへの変化 People & Process & Product_Technology 再利用拡大など効率化のため、製品内部へAUTOSARなどのプラットフォーム構造折込が必要その上でプロダクトライン開発から分析された構造を織り込んでいく。 BOSCHが以前から提唱 V&V&Vへの変化 Verification & Validation & Valuation V字プロセスのみの時代から、次の開発のプロダクトラインを考えながら取り組んでいく時代へまとめると・パラダイムシフトが10年毎に起きているぞ・今後も継続的に起きていく、と想定される。・効率的で、高信頼な開発手法変革が求められている。・パラダイムシフトは、インターネットに潜伏して急拡大するため、見えにくくなっている（サイレントパラダイムシフト）一区切り質問：C言語を補完する形でモデルベースなどが使われてきているが、今後、C言語は補完していくべきものなのか解答：C自体、どんどん改定されている。しかし、アーキテクチャを変えると、言語としてがらっと変わる。　　　モデルでかぶせて解決している。部分的にはCは残るだろうが、そこにしがみついてはダメ ②機能安全の課題具体的にこういうやり方というのは機能安全規格に書いていない機能安全とは？昔からある流れ。普通のこと。本質安全：立体交差にすれば、踏切を渡って事故に遭遇する可能性はない機能安全：現実は線路をすべて立体交差にすることはできない世の中の考え方のすべてが機能安全リスクベース設計になっている開発の全工程で機能安全は関係してくるソフト開発者が機能安全をわかっていれば、受け取るべき仕様がきちんと分かる機能安全の規格を頭にいれることをおすすめする何を上流からやらなければならないかすべて書いてあるただ、どのレベルまでというのが書いてない機能安全を補完する方法が必要自動車機能安全規格の解釈はJasPar,JARI活動で共有されてきた。そこから踏み込んだ相場観は、すべては議論できない。（各社活動）様々な動き・GSN, D-Case, SafeML, SCDL ・GSN: Goal Structure Notation (2011）システムが達成すべき目的や性質について、その達成を導く方法・思考を可視化する際に用いる記法・D-Case: Dependability Case （2013） GSNを利用した合意の表記法・SafeML: Safety Modeling Language 産総研活動：安全関連情報をコミュニケーションよく交換するモデリング記法。sysMLのテンプレート。・SCDL: Safety Concept Description Language（2013～）エレメントの表記法、安全要求の表記法、それらを統合した安全コンセプトの表記法 DCASEの基本であるGSNは非常に簡易な基本表記あっという間に覚えれる ③何が停滞し、何がブレークスルーしているのか？・モデリング標準化の停滞、認識遅れ UML1.0以降若干のマイナーチェンジはあっても大幅な変更はない sysMLも10年間ほぼ変更なししかし、ローエンドの動きは活発(MARTE,EAST-ADL) UMLもsysMLも10年前のもの、モデリング標準化は停滞している。プロダクトラインのフィーチャー図を織り込む作業が進んでいない状態遷移表はモデルに織り込まれるのか？ DSM提案（状態遷移表同様表的表現）は？ Matlab/Simulinkスタイルガイドは進んでいるが、sysMLスタイルガイドが標準化に至っていない MBSEを補完するGSN、D-Case、SCDL（SCN）などの提案が始まって、融合が歩みだした。 MBSEもMBD/MDDも安全分析をどう支援／織り込むかは途上（STAMP、安全分析）コンパイラ技術/CAEの進化 2010年頃からプログラム言語提案が活発化 Javascript/Webエンジンの競争過熱。コンパイラの解析エンジンが進化いろんな言語が提案された Rubyは簡単だと思われるが、外国だと黒魔術言語と呼ばれるオブジェクト言語と関数言語がバランスよく入っているオブジェクト指向にアーキテクチャ指向へ、プロトタイピングを視野に入れる形でプログラミング言語が変わってきているそして、コミュニティ指向の動きから、シンプルでわかりやすくて考えやすい言語のニーズが高まる新たな言語が生まれるときが来たという印象一区切りじゃあ明日からどうするか上流にシフトしていくとソフトだけの世界ではなくなってくるそれを頭に入れておく＝システム記述、アーキテクチャ記述／技法これを“ヘテロジニアス”な世界と言います。とにかくC言語の弱いところを意識し、サポートする道具を使いながら開発していくモデリングも併用するが、モデリングも注意して使っていこう状態遷移表を必ず確認安全分析などのいろんな分析をする。それは製品開発プロセスの中で誰かがやる。自分がやるようになると、視野が広がる派生開発ではフィーチャ図モデリングにはGSN,D-CASEといったものも出てきている開発全体をまとめたときに、きちんと安全規格通りに設計しているか一言で説明せよ、レポート数枚で書いてみよといったことになるそうしないとお客さんにわかってもらえないこれをまとめておくのがGSN,D-CASE プロトタイピングを意識 GSN, D-Case, SafeML, SCDL というのが一昨年くらいから取り組まれている機能安全は、ドキュメントやプロセスにすべて名前が付いている世界中で同じ名前→ひと目で、一言で意思疎通できる機能安全は必ず目を通そうドキュメントはステークホルダーにしっかりフィードバックしようと機能安全では書いてある。フィードバックはつまりアジャイルのことアジャイルは組込みに無縁の言葉？いや、違う昔15年前と今とでは環境が違う様々なことがツールでサポートされるようになっただからアジャイルが効いてくるシミュレーションが必要だが、いまはそれができる構成管理も進化したし普及した。 15年前とアジャイルという言葉の意味自体が違うアジャイルはもはや開発で当然のようにするべきこと・プロトタイピング− リファインメント− Ｃ言語実装のアイテレーションが本来あるべき姿。・会話型開発を意識・その上で、MBD，MDD、シミュレーション、IDE、言語、ツールを組み合わせて選択しよう。・ひとつの言語で、すべて（フルスタック)開発するのがベストと言えるか、場面場面で自問自答してみよう。・ADLを意識しアーキテクチャ設計を意識しよう（機能安全でも意識している）。プログラム＝アーキテクチャ＋振る舞いフィードバック、プロトタイピング、会話型を意識動く、見える（ヴィジュアライズ）、反応をもらう、を意識サイレントパラダイムシフトは10年ごとに来ます。自ら情報を取りに行って、備えましょう。 21世紀に求められる人材グローバル対応できる人、新技術に怖がらずどんどんチャレンジできる人、自分で切り開ける人、の次は？今、経験できるひとが少なくなってきているが、情報はたくさんある情報を用いて、”擬似仮想体験からの習熟能力”が重要になっている情報収集の頭でっかちではなく、インターネットの世界の中で、あたかも自分が経験したような、スキルに昇華させる能力が求められる質疑 Q,パラダイムシフトが勝手に来るのではなく、みんなで起こそう。パラダイムシフトに取り残される人をなくして、新しくパラダイムシフトを起こそう、どうすれば？ A,みんなが発信者。発言しないと変わらない。気がついたことは騒いでいこう Q,ソフトウェア、アーキテクチャ、システムと移り変わったがアーキテクチャエンジニアリングの時期が短かったアーキテクチャエンジニアリングの今についてどう思うか A,日本ではアーキテクチャ工学という言葉が流行らない、ソフトウェアアーキテクチャという言葉だけ触れられた印象。もっともっと意識していこう ADLの考え方は、MATLAB/simulinkで強いところなのでこれらを使っているとアーキテクチャ工学を自然と意識していく