2016年09月15日

アーキテクチャとアーキテクティング

アーキテクチャとは何か、アーキテクティングとは何か。よく聞かれるので簡単に説明をしておきたいと思う。
もちろん、アーキテクチャとは、もとともは建築物のことを指すものである。しかしながら、現在では、CPUのアーキテクチャや製品のアーキテクチャなどの言葉があるとおり、より広く使われるものである。
アーキテクチャとは、“システムと外界(コンテクスト)との関係”及び“システムを構成する要素とその要素間の関係”のことを指す。
慶應SDMでも価値交換のアーキテクチャを表すために価値連鎖分析(CVCA:Customer Value Chain Analysis)や、欲求のアーキテクチャを表す欲求連鎖分析(WCA : Wants Chain Analysis)なども使ったりする。

アーキテクティングとは、アーキテクチャを設計する行為をさして呼ばれるものである。一般的にアーキテクティングを説明すると、大きく以下の2つのポイントが重要となる。
•複数の視点(viewpoint)からシステムを見て、それぞれの視点における要素と要素間の関係をデザインする
•デザイン結果として見えるもの(view)の重ねあわせ(Allocation)を実施する
これをISO/IEC/IEEE 42010 Systems and software engineering – Architecture descriptionでは、以下のように示している。
つまり、対象となるシステム(System of Interest)にはアーキテクチャが存在する。また、対象となるシステムにはステークホルダ(Stakeholder)が存在する。そのステークホルダには関心事(Concern)があり、その関心事に対応した視点(Viewpoint)を設定することができる。その視点から見えるもの(View)が複数存在し、視点と視点から見えるものを集めたものがシステムのアーキテクチャの表現(Architecture Description)である。
具体的には、以下のように考えることができる。一般的な技術システムでは、ステークホルダとして、利用者と開発者が考えられる。利用者としてはどのように使うのか、どのような機能を持っているのかといったことが気になる。一方で、開発者としてはどのように機能を実現するかがきになると考えられる。このため、どのように使われるかの視点(運用視点:Operational Viewpoint)での設計(Operational View)と、どのような機能をどのようなサブ機能で実現するかの視点(機能視点:Functional Viewpoint)での設計(Functional View)と、どのようにサブ機能をハードウェアやソフトウェアで実現するかの視点(物理視点:Physical Viewpoint)での設計(Physical View)で考える。運用をどのような機能要素で実現し、機能要素をどのような物理要素で実現するかを重ねあわせによって決定する。これが一般的な技術システムにおけるアーキテクチャ設計である。同様なことを、組織の設計では、役割(役割視点)と組織(組織視点)で設計するなどによって実現できる。
System Architectureに関する名著としては、"the art of systems architecting"がある。この本では、ArchitectingはEngineeringよりもよりArt側の側面が強く、Science側の側面が弱いといっている。
実際、Architectingでは、解空間が広く、自由度が高いために、いわゆるセンスのようなものによるところが大きい。(もちろん、このセンスはある程度、後天的に身につけることが可能である)
System of SystemのArchitectureとなると、これまたいろいろな難しさがでてくるのであるが・・・・・
posted by しらぴー at 21:07| Comment(0) | システムズエンジニアリング

2015年09月14日

モデルベース・システムズエンジニアリング (MBSE)の進め方

最近、いろいろなところで、いろいろな会社の人から、モデルベース・システムズエンジニアリングの相談を受けます。そして、すごく多いのが、「Sysmlを使って書いてみたんですけど・・・・」という相談です。
いつも、「ん?」と思うのですが、あまりにも多くこのような話の持ってこられ方をするので、「なんでこんなことになっているんだろう」と不思議に思ってしまいます。
もちろん、「モデルベース・システムズエンジニアリング」というからには、「モデル」を活用した「システムズエンジニアリング」であることには違いないのですが、システムは多様ですし、その設計のアプローチも多様なので、そんなに単純にはすすみません。
自分としても、エアバス社(当時のダイムラークライスラーエアロスペース、後のEADS Astrium社)に駐在していたいときに、モデルベースシステムズエンジニアリング(MBSE)を立ち上げたメンバーの一人だったので、その立ち上げのときの苦労とアプローチをはっきりと覚えています。(ちなみに、そのエアバス社は、SysMLを作ったメンバー会社の一つです)
では、当時はどんな議論からはじめていたかというと、まずは、何のためにモデルベースシステムズエンジニアリングをおこなうのか、という点です。コスト削減のためなのか、スケジュール短縮のためなのか、あるいは品質向上のためなのか、目的によって、そのあとの検討が全くかわってきますので、まずはそこを明確にしました。もちろん、自社の戦略ははっきりしていますので、ここではそれほど時間がかかりませんでした。
次におこなったのが、では、開発プロセスの中で、どこをどのような(抽象度の)モデルにすれば、その目的を実現できるかの検討でした。これは、開発プロセスを明確にし、どこでどのようなモデルがあれば、よいか、そのためにはどのような情報が必要なのか、といったことを一つ一つ検討し、ライフサイクルを通じてシステムモデルを活用することで上記の目的が実現できるモデルベース開発をデザインすることでした。つまり、現在モデル化をしていない何を、どのようなモデルにするか。あるいは、現在すでにモデル化をしている何を、どのようなモデルに変更するかを考えることです。目的を考え、このモデルベース開発のアプローチをデザインすることだけで、ほぼ1年を有しました。
その後、どのようなモデルを活用するか、とうことを考え始めたのですが、適切にシステムモデルを標記するための記述法がなかったために、SysMLを作る方向に進みました。
ちなみに、結果として、当該部署ではSysMLは使わないこととなりました。あまりにも汎用的すぎて、目的のためには”Too much"だったようです。
もしモデルベースシステムズエンジニアリングをはじめたい方は、もちろん、SysMLの勉強として、いろいろなものをSysMLの標記法で書いてみるのはいいですが、本格的に進めるためには、やっぱり上記のようなことをしないと単に書いてみただけで、目的に適合しない活動になってしまうようです。
でも、そのためには、まずはシステムズエンジニアリングを理解しないと検討すらできないという問題点にぶつかってしまう場合も多いのですが。。。。




posted by しらぴー at 20:56| Comment(0) | システムズエンジニアリング

2015年06月12日

インダストリー4.0リファレンスアーキテクチャモデル:RAMI4.0

ドイツが国をあげて進めているインダストリー4.0ですが、その実行の中心的な役割をになっている「インダストリー4.0プラットフォーム」が、「インダストリー4.0の実装戦略 (Implementation Strategy 4.0)」を発表しました。(ドイツ語では、「Umsetzungsstrategie Industrie 4.0」となっています。)
この中でとても興味をひかれたのが、「Reference Architecture Model Industrie 4.0(RAMI4.0)」という「インダストリー4.0リファレンスアーキテクチャモデル」です。

スクリーンショット 2015-06-11 0.42.58.png
(出展:Umsetzungsstrategie Industrie 4.0)
見た瞬間に、「あ、またこのパターンできたか」という風に感じましたが、まさにCEN-CENELEC-ETSIのSmart Grid Coordination Groupがつくった、Smart Grid Reference ArchitectureにでてくるSmart Grid Architecture Model (SGAM) Frameworkにそっくりな形態となっています。

RAMI4.0をみてみると、「Life Cycle&Value Stream」と「Hierarchy Levels」で平面をつくり、そこに縦軸として「Layers」を配置しています。
「Life Cycle&Value Stream」では、IEC62890「産業用プロセス計測・制御・オートメーションにおけるシステム・機器に関するライフサイクルマネジメント」をベースとしているようです。SGAMでは、「Domain」にあたる軸ですね。「SGAM」では、ライフサイクルというよりもValue Streamというほうが適切で、発電してから末端の機器にいたるまでの流れになっています。RAMI4.0では、大きく「Type」と「Instance」にわけ、「Type」の中が「Development」と「Maintenance/usage」に、「Instance」の中が「Production」と「Maintenance/usage」にわかれています。
「Hierarchy Levels」は、IEC62264/61512から構成されています。IEC62264は、企業の経営と制御システムとの統合を目指す標準「Enterprise-control System Integration」となっています。これと「バッチ制御」の標準であるIEC61512を組み合わせ、インダストリー4.0用にいくつかを追加したものとなっています。

スクリーンショット 2015-06-11 6.24.53.png
(出展:Umsetzungsstrategie Industrie 4.0)
これはSGAMで「Zones」という名前でいわれていたものと同様で、奥にいくほど、より上位の概念となるようになっています。
「Layers」は、ほぼSGAMの「Interoperability Layer」を踏襲したものとなっていますが、最後の層がSGAMでは「component」だったのが、「Integration」と「Asset」となっているます。

スクリーンショット 2015-06-11 6.29.17.png
図Smart Grid Architecture Model (SGAM)
個人的には、SGAMも、RAMI4.0もこの縦軸はいまいちかなぁ〜と思っています。
というのも、情報というのは、決して、「Function」の下だけにあるものではなく、「Function」の結果としての「Information」を「Business」がつかうこともあるので、「Information」をどこかの層にいれてしまうと、誤解をあたえてしまうからです。その点では、DoDAF2.0 (DoD Architecture Framework)はよくできていると思います。DoDAF2.0では、データやインフォメーションは、あらゆるレベルで使われるため、すべてのレイヤーに共通なものとして用意されています。
DoDAF-V2.0-Viewpoints2.jpg
図 DoDAF2.0のViewpoints
但し、DoDAFは、時間と空間の概念をFrameworkのレベルにいれていないからできているのですが。
本質的にはこちらのほうが正しいかと思っています。

詳細は、上記のような懸念点はあるにしても、俯瞰的に捉えるArchitecture Reference Modelとして、時間x空間xEnablerという組み合わせでつくるのは有効なようですね。


posted by しらぴー at 16:34| Comment(0) | システムズエンジニアリング