プラグアンドプレイ








プラグアンドプレイ (Plug and Play, PnP) は、パーソナルコンピュータ(パソコン)に周辺機器や拡張カード等を接続した際にハードウェアとファームウェア、ドライバ、オペレーティングシステム、およびアプリケーション間が自動的に協調し、機器の組み込みと設定を自動的に行う仕組みのことである。パソコンのユーザビリティ(使い勝手)を向上させる技術の1つ。ドライバの自動インストール機能 とも呼ばれる。


つないだら (plug)、ユーザが何か特別なことをしなくても実行 (play) できる、という意味である。1995年に登場したWindows 95の主要な機能の1つとして紹介され、この言葉が定着した。なお、これに類する概念や機能をもつパソコンは、1980年代にもいくつかの環境で存在していた。




目次






  • 1 概要


  • 2 歴史


    • 2.1 プラグ・アンド・プレイ前史


      • 2.1.1 Apple IIによる実装


      • 2.1.2 MSXによる実装


      • 2.1.3 Macintosh による実装






  • 3 実例


  • 4 関連項目





概要


初期のコンピュータでは、周辺機器を接続してもすぐには使えず、機器を動かすための設定をユーザ自身が行わなければならないことが多かった。これは、例えばプリンターの印字濃度の調整といった具象的でユーザに近い理解しやすい水準のものではなく、I/Oポートや割り込みの割り当て設定といった、よりハードウェアに近い低水準のものだった。これらの設定にはハードウェアやオペレーティングシステムに関する知識がある程度必要になるため、コンピュータに詳しくないユーザにとっては使い勝手を悪化させる一因になっていた。


プラグアンドプレイは、周辺機器等や拡張カード等をパソコンに接続した際に、ハードウェアやオペレーティングシステムが自動的に機器を認識してリソースの割り当てやデバイスドライバの導入などの作業を行い、ユーザが何もしなくても機器を使えるようにする仕組みを指す。


しかし、この概念を実装したごく初期の環境では想定外の動作がみられる事もままあり、大抵はユーザーの望まない結果をもたらした。そのため、Plug and Pray(つなぎ、そして祈れ)と揶揄されることもあった。



歴史


プラグアンドプレイとは、Windows 3.1の次の世代のオペレーティングシステムとなるWindows 95の主要機能の1つとして登場した概念・規格・用語である。


しかし、多くのパソコンやパーツのメーカーがひしめくPC/AT互換機市場では各社が足並みをそろえる事も容易ではなく、登場からしばらくの間は混乱が続いた。Windows 95時代のパソコンは、周辺機器を接続するコネクタもUSBやIEEE 1394ではなく、AT/PS/2ポートやシリアルポート、パラレルポート等のレガシーデバイスを使用していた。 また、パソコンによってはプラグアンドプレイに対応しない古い規格のハードウェアを用いているものもあり、それらがシステムに混在することでプラグ・アンド・プレイがうまく動作しないケースもあった。


その後、周辺機器や拡張カードを接続するインタフェースの世代交代や、オペレーティングシステムの改良が進んだことで、Windows 98 SEやWindows 2000が登場する頃には、この種の問題は改善された。


Linuxでは、本来の用途が必ずしもエンドユーザ向けのデスクトップ環境を第一義とはしていない面や、安定したレガシーデバイスやデファクトスタンダードで固めたハードウェア構成を指向する傾向も強かった事などから、多彩な周辺機器に柔軟に対応しなければならないエンドユーザ向けの分野では大きく遅れをとっていた。しかし2000年代に入ると、KNOPPIXなどハードウェアの認識機能の改良を進めたディストリビューションも出現してきている。



プラグ・アンド・プレイ前史


本来のプラグ・アンド・プレイという規格・用語はPC/AT互換機とWindowsによるものである。しかし、これらの概念や実装は一朝一夕にして成立・普及した訳ではない。30年におよぶパーソナルコンピュータの歴史の中には、その前史とも言えるいくつかの環境や実装が点在する。



Apple IIによる実装


プラグ・アンド・プレイのルーツ的存在と言えるものとして、1970年代末に登場したアップルのApple IIを挙げることができる。


Apple IIにも、原始的なプラグ・アンド・プレイに似た仕組みが整備されていた。Apple IIの拡張カードには、最大256バイトまたは2048バイトの原始的な基本制御プログラムを書き込んだROMを搭載でき、カードが差し込まれたスロットをプログラム(BASICのプロンプト)から PR#n (出力)、IN#n (入力) と指定するだけで使えるようになっていた。Apple IIのカードスロットには当時主流のS100バスとは異なり、ハードウェアがどのスロットに装着されているかをソフトウェア的に識別できる仕組みがあり、同じカードを複数挿してもそれぞれのカードを識別できるシステムになっていた。また一部のカードでは小規模なアプリケーションソフトまで書き込まれており、特定キーを押下することで起動するものもあった。


当時はプラグ・アンド・プレイという語は存在しておらず、これによって実現される環境も、現在のものとは程遠い、原始的な代物である。しかし、当時の貧弱な環境ではこれでも十分、かつ先進的なシステムと言えた。



MSXによる実装


1980年代半ばに登場した8ビットパソコンMSXでは、本体に「拡張スロット」を用意していた。これは、ゲームなどのソフトウェア供給媒体としてのROMカセットの差し込みスロットと、ハードウェアの拡張・増設用バス、メモリソケットなどの役割を一つにまとめたものである。


MSXではこのスロットを利用し、カートリッジを単にソフトウェア供給媒体として利用するのみならず、ハードウェアの標準的な拡張・増設手段として用いた。ハードウェアの拡張を行うカートリッジには、現在のシステム環境でのデバイスドライバに相当するBIOSや、アプリケーションなどのソフトウェアを搭載したROMを内蔵していた。このROMの容量は1ページ16KBからで、必要に応じて複数ページに渡って搭載することも可能で、デバイスドライバやBIOSのみならず、当時としては大規模な[独自研究?]アプリケーションまで供給できた。


MSXのシステムは起動時にすべてのスロットのROMを一度ずつ呼び出し、初期化の機会を与えた。この時に各々の機器のROMはシステムの任意のフックを書き換えるなどし、デバイスドライバとしての自身のROMを呼び出させるようにした。現在で言えば、ドライバのインストールをPC起動時に毎回行う状況に近いと言える。ゲームソフトなどの単純なアプリケーションは、この初回の呼び出しの機会からそのまま制御を返さないことで実現する。


この特異なスロットの仕様を活用した例として、プリンタ用インターフェイスに漢字ROMとかな漢字変換IMとワードプロセッサを内蔵したカートリッジや、増設RAMとオペレーティングシステム(DOS)やグラフィカルユーザー環境を搭載したカートリッジなどもある。[要出典]



Macintosh による実装


Apple IIの後継に当たる Macintoshは、当初は拡張スロットに相当する機能は持たず、1987年のMacintosh IIシリーズから拡張スロットとしてNuBusが採用された。それまでの多くの拡張スロットがマイクロプロセッサからの信号を分岐する様な、ハードウェア構成に直結した実装だったのに対し、 NuBus は適切なデバイスドライバが用意されればプロセッサに依存しない汎用的な実装規格である。また、スロットごとにリソースを調停する機能を持ち、現在のPCIバスとほぼ変わらないプラグアンドプレイ機能を実現していた。
のちに 1995年に発表されたPowerMacintoshシリーズでは、より高速で汎用性の高いPCIバスが採用された。



実例


プラグアンドプレイが標準的に実現されているインタフェース規格には、以下のようなものがある。



  • NuBus


  • PCカード/CardBus/ExpressCard


  • PCI/AGP/PCI Express

  • USB

  • IEEE 1394

  • eSATA


これらに先んじて、半自動的なプラグアンドプレイを実現していたインタフェース規格には、以下のものがある。



  • MCA

  • EISA

  • NESA


また、以下のレガシーなインタフェース規格にも、後付けでプラグアンドプレイが実現された。



  • ISA

  • Cバス

  • シリアルポート

  • パラレルポート

  • VGAコネクタ (VESA DDC)


  • ATA/ATAPI(ケーブルセレクト)


  • SCSI (SCAM)



関連項目



  • ホットスワップ

  • ユーザビリティ

  • Universal Plug and Play




Popular posts from this blog

MongoDB - Not Authorized To Execute Command

How to fix TextFormField cause rebuild widget in Flutter

in spring boot 2.1 many test slices are not allowed anymore due to multiple @BootstrapWith