相互運用性




相互運用性(そうごうんようせい、英: interoperability)とは、さまざまなシステムや組織が連携できる (相互運用できる) 能力に関する特性である。この用語はしばしば技術システム工学の意味で用いられるが、その代わりにシステム間の性能に影響を与える社会的、政治的、組織的な要因を考慮に入れた広い意味で用いられることもある。




目次






  • 1 定義


  • 2 ソフトウェア


  • 3 医療産業


  • 4 治安


  • 5 相互運用性の達成


  • 6 力と市場支配への疑問としての相互運用性


  • 7 関連項目


  • 8 脚注


  • 9 外部リンク





定義


IEEEは相互運用性について「2つかそれ以上のシステムまたはコンポーネントが情報交換でき、また交換した情報を使用できる能力」[1]と定義している。


電気通信では、この用語を以下のように定義している。



  1. システム、部隊、もしくは軍が、他のシステム、部隊、もしくは軍にサービスを提供し、またサービスを受けることができ、また交換したサービスを使って互いの作戦をより効果的にできる能力。


  2. 情報やサービスを電子通信システムや電子通信機器の品目やその利用者間で直接かつ満足に交換できるとき、それらの間に達成される条件。相互運用性の度合いは特定の状況を参照して定義されるべきである。


出典: Federal Standard 1037CおよびDepartment of Defense Dictionary of Military and Associated Termsの支援するMIL-STD-188より


送受信兼用の無線機において、相互運用性とは3つの特徴からなる。



  • 通信路(周波数、装置および信号の互換性)に互換性があること

  • 無線システムの受信可能範囲や適正な信号強度を有すること

  • 拡張可能な収容能力があること



ソフトウェア








相互運用性: 2つのネットワークゲームを遊んでいる様子。プレイヤークライアントの片方 (左上) はサン・マイクロシステムズの下で、もう片方はGNU ClasspathとJamVMの下で走っている。アプリケーションは同じバイトコードを実行し、通信に標準のRMI-IIOPメッセージを使って相互運用している


ソフトウェアにおいて相互運用性という用語は、異なるプログラムが交換形式の共通部分を介して、データを交換したり、同じファイル形式を読み書きしたり、同じプロトコルを使ったりする能力を記述するために使われる (同じ実行ファイルを異なるCPUプラットフォーム上で実行する能力は相互運用性の定義に想定されて'いない')。相互運用性の欠落は、プログラムの設計過程において標準化への配慮の欠落を招く結果になりうる。実際、相互運用性はコンピュータの世界の標準に準拠しない部分では、当たり前のものではない。


ISO/IEC 2382-01 Information Technology Vocabulary, Fundamental Termsによると、相互運用性は以下のように定義されている: 「各種の機能単位の間で、利用者がそれらの機能単位に固有の特性をほとんどあるいは全く知ることなしに、通信したり、プログラムを実行したり、データを転送したりできる能力」 [1]


プログラムの利用者は他のプログラムである場合もあり、もし後者が相互運用性を持つことを要求されているプログラムの集合の一部であるなら、他の機能単位の特徴に関する知識を持つ必要もあり得るので、この定義はいささか曖昧であることに注意されたい。
この定義は相互運用性の技術的な側面に焦点を当てているが、相互運用性はしばしば組織的な問題であることも指摘されてきた: 多くの場合相互運用性は関係機関に重大な影響を与え、所有権の問題をもたらし (人々はそれらのデータを共有することを望んでいるか?)、労使関係であり (人々は訓練を受けているか?)、ユーザビリティである。この文脈では、より適切な定義が「ビジネスプロセスの相互運用性」という用語でとらえられている。


相互運用性はネットワーク外部性などの、重要な経済的影響を持ちうる。もし競争相手の製品が (特許、企業秘密もしくは協働の失敗などの原因により) 相互運用性を持っていなければ、その結果はおそらく独占や市場の失敗となるであろう。このことから、利用者コミュニティや政府は各種の状況で相互運用性を促す措置を講じるのが賢明であろう。たとえばイギリスにおいては、e-GIFと呼ばれる電子政府に基づいた相互運用性の主導が存在する。利用者コミュニティに関する限りは、中立的な第三者機関がビジネスプロセスの相互運用性のための標準を作成している他の中立的な機関の一例は、Internet Engineering Task Force (IETF) のRFC文書である。



医療産業






新しい技術が病院や研究所に導入される速度はますます勢いを増しつつあり、これらの技術革新の多くは、もし効果的に組み込まれたのであれば相乗的に影響し合う潜在能力を持つ。「プラグアンドプレイ」相互運用性 – 医療機器をその箱から取り出し、容易に別の機器とともに機能させることができる能力 – の必要性が、医療介護の提供者と業界の両者から大きな関心を引きつけてきた。


相互運用性は患者がテクノロジを最大限に生かす助けとなり、産業界での技術革新も促す。異なる製品を複雑で高価なインターフェースなしに組み合わせられるなら、小さな会社が分野に進出して専門化された製品を開発できる。相互運用性がなければ、病院は、互換性のある機器一式を提供するが一領域に特化していない大きな業者に頼ることを強いられる。相互運用性は競争を推進し、競争は技術革新と品質の向上を促す。


消費者向け医療機器の主要な生産者であるインテルの観点では、業界が相互運用性を達成する能力に影響を与える6つの大きな要因がある。第一に相互運用性を持つ製品への需要が必要である。第二に、この分野で相互運用性が何を意味するのかを定義する、標準と規則が必要である。第三に、業況が製造業者にその製品を相互運用可能にするよう促さなければならない。第四に、解釈する会社にとってしばしば複雑なものになりがちな標準をより容易にするガイドラインが存在しなければならない。第五に、独立した検査によって適合性が検証されなければならない。そして最後に、相互運用性は積極的に推進されなければならない。無線通信技術の急進は、相互運用性が達成可能なものであることを実証している。


医用生体工学の業界における現状は、まだ相互運用性のあるシステムの開発につながる途上の過程である。関心を持つ病院の潜在的な市場が存在し、相互運用性のための標準が開発中である。とはいえ、現在の業況は製造業者が相互運用性を達成するよう促しているようには見えない。たとえば、電子カルテ (EMR) を使っている病院は16~20%に過ぎない。EMRの採用率がこのように低いため、ほとんどの製造業者は相互運用性に投資することなしにやり過ごせている。実際、相互運用性が達成されていないことにより一部の製造業者が自社の製品間での互換性を宣伝し、競争相手の製品を排除することが可能になっている。EMRの採用を推進することにより、インテルなどの会社は、必要としている相互運用性のある製品を病院が集めて活用できる環境を作ることを望んでいる。



治安






相互運用性は警察、消防、救急医療、およびその他の公共の健康や安全に関わる部門にとって重要である。なぜならば第一対応者は大きな緊急事態が発生したときに連絡できる必要があるからである。伝統的に、米国の政府機関は互換性のないバラバラのハードウェアを広く使っていたため、情報を交換できなかった。computer-aided dispatchシステム (CAD) や records managementシステム (RMS) のような政府機関の情報システムは主に単独で機能する、いわゆる「情報の孤島」であった。政府機関はこれらの孤立システム間に、非効率で応急処置的な方法による橋渡しをしようと試みたが、大きな政府機関は限定的に相互運用性のあるシステムを実現し始めていた。これらの方法は不十分であり、国家の治安分野に相互運用性が欠けていることは国防総省と世界貿易センタービルへのアメリカ同時多発テロ事件によって明らかになる。相互運用性が欠落していることのさらなる証明はときハリケーン・カトリーナの後始末に取りかかったとき明らかになった。


連邦政府の状況とは対照的に、ユタ州を含むいくつかの州は、すでに長足の進歩を遂げていた。ユタ州ハイウェイ・パトロールとユタ州の他の部門は、バウンティフルに本拠を置くFATPOT Technologies社の技術を使い、州全体にわたるデータ共有ネットワークを構築していた。


アメリカ合衆国政府は国家の治安部門に相互運用性が欠けている問題を克服するために努力を始めている。国土安全保障省のOffice for Interoperability and Compatibility (OIC) はSAFECOM計画とCADIP計画を推進している。これらのシステムは政府機関のCADと他のITシステムを統合することによってそれら政府機関を助けるよう設計されている。


OICはCADIP計画を2007年8月に立ち上げた。この計画は、OICがシリコンバレーを含む各地の政府機関と提携して進めようとしている。この計画はために最優良例を確認するために事例研究方式を用い、管轄区域を越えてCADシステムを結びつけることに挑戦する。これらの経験は、治安政府部門が相互運用可能なCADシステムを構築し、地方、州、および連邦の境界を越えて通信するために使える道具や資源を作成するであろう。



相互運用性の達成


相互運用性を達成するには4つの手段がある: 製品工学を通して、業界とコミュニティの協調、技術と知的財産を利用できること、そして標準の実装である。









力と市場支配への疑問としての相互運用性






相互運用性は専門家にとっての問題であるとみなされ、その日常生活に対する影響はときに過小評価される傾向がある。マイクロソフト対欧州委員会の事件は、相互運用性への懸念がいかに力関係に関わる問題であるかを示している。2004年、欧州委員会はマイクロソフトがその市場での力を悪用して、Windowsのワークグループサーバと非マイクロソフト製のワークグループサーバとの間で恣意的に相互運用性を制限していたことを発見した。そうすることにより、マイクロソフトは、企業ITネットワークの核心であるワークグループサーバのオペレーティングシステム市場において、自社の支配的な地位を守ることができた。マイクロソフトは、ライバル企業が対等な立場で競争できるように、完全で正確なインターフェース文書の開示を命じられた (「相互運用性の是正」)。2005年6月の時点では、欧州委員会はこれを行うためマイクロソフトによる以前の提案を不十分であるとして退け、新しい提案の市場試験を行っている。


最近のマイクロソフトの相互運用性に関わる努力は、相互運用性に対する同社の姿勢と熱意の変化を示しているかもしれない。これらの努力にはMicrosoft Officeのファイル形式をECMAのOffice Open XMLに移行すること、およびパートナー企業数社との相互運用性に関する合意を含む。それら最近の協力合意のうちもっとも有名なものはNovellとの提携である[2][3][4]。


相互運用性は欧州議会でのソフトウェア特許論争 (2005年6月~7月) でも現れた。批評家は、相互運用性のために必要とされる技術に関する特許はRANDライセンス (妥当かつ公平なライセンス) の下に置かれるので、顧客はライセンス料金を二度 (一度は製品自身のために、そして適切な場合には、特許で保護されたプログラムを製品が使うためにもう一度) 支払わなければならないと主張している。



関連項目



  • 統合作戦

  • C4Iシステム

  • Synchronization and Management of Different Distributed Enterprise Models (企業モデリングの相互運用性)

  • 人工知能

  • 規格

  • 互換性


  • IETFのRFC



脚注




  1. ^ Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990.(iftikahr)



外部リンク




  • CIMIT - Center for Integration of Medicine and Innovative Technology - the MD PnP Program on Medical Device Interoperability(英語)


  • Simulation Interoperability Standards Organization (SISO)(英語)


  • Interoperability. What is it and why should I want it. Ariadne 24 (2000)(英語)


  • Interoperability Summit(英語)


  • InterOP NoE Project(英語)


  • OA Journal on Interoperability in Business Information Systems(英語)


  • University of New Hampshire Interoperability Laboratory - コンピュータネットワーク技術の相互運用性に関する研究施設の筆頭(英語)


  • Microsoft Interoperability(英語)


  • Interoperability vs. intraoperability: your open choice. Bob Sutor blog, 2006年12月6日.(英語)


  • i14y.net Webサービスを通したJBossアプリケーションサーバ、Microsoft .NET、BEA WebLogicおよびIBM WebSphere間での相互運用の可能性に関する研究を提示する(英語)


  • La France v. Apple: who’s the dadvsi in DRMs?, Nicolas Jondet (エディンバラ大学), SCRIPT-ed, 2006年12月(英語)




Popular posts from this blog

'app-layout' is not a known element: how to share Component with different Modules

SQL update select statement

android studio warns about leanback feature tag usage required on manifest while using Unity exported app?