技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/04/03 02:40 UTC 版)
軌道船諸元(OV-105エンデバー号) 全長:37.237m 全幅:23.79m 全高:17.86m 空虚重量:78,000kg 離陸時総重量:111,000kg 最大着陸重量:100,000kg 主エンジン:ロケットダイン社製ブロックII-SSME3基。1基あたり海面推力1.752MN(178トン、104%推力発生時) 最大搭載量:25,060kg 貨物室寸法:4.6m×18.0m 運用高度:190〜960km(100〜520海里) 最大速度:秒速7.743km(時速27,870km マッハ22.57相当) 軌道範囲:2,009km(1,085海里) 定員:飛行によって異なる。初期の頃は最小人員の2名で飛行したが、後の多くの飛行では5名になり、その後7名(船長、パイロット、数人の搭乗運用技術者、まれに航空機関士(フライトエンジニア))で構成するのが一般的になった。STS-61-AとSTS-71の2回の飛行では8名が搭乗した。STS-3xxと呼ばれる緊急救助飛行では、11名(4人乗りで打ち上げて、7人を移乗)を搭乗できるよう検討されていた。 外部燃料タンク諸元(超軽量タンク) 全長:46.9m 直径:8.4m 燃料容量:2,025m3 空虚重量:26,535kg 発射時重量:756,000kg 固体燃料補助ロケット諸元 全長:45.46m 直径:3.71m 空虚重量(1機あたり):68,000kg 発射時総重量(1機あたり):571,000kg 推力(発射時、海面推力):12.5MN(1,281,360kg) 完成型詳細 全長:56m 発射時総重量:2,000,000kg 発射時総推力:30.16MN(3,091,680kg)
※この「技術的詳細」の解説は、「スペースシャトル」の解説の一部です。
「技術的詳細」を含む「スペースシャトル」の記事については、「スペースシャトル」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2018/09/08 06:36 UTC 版)
いまでも、ヴォルガ水力発電所はヨーロッパで最大の発電所である。長さ725メートル、高さ44メートルのコンクリート・ダムはヴォルガ川にある。これをサポートしているのが、3250メートル、47メートルのアースフィルダムである。ダムの上には鉄道、道路が通っている 現在の発電能力は2,650 MWで、年間エネルギー出力は1,200,000 KW時である。発電機は22基あり、115 MW発電機が9基、 125.5 MWが8基、120 MWが5基ある。魚道には11 MWの発電機も設置されている。 4.9キロメートルのダムでヴォルゴグラード貯水池を作っている。現在ルスギドロの子会社であるヴォルガ水力発電所社が管理している。
※この「技術的詳細」の解説は、「ヴォルガ水力発電所」の解説の一部です。
「技術的詳細」を含む「ヴォルガ水力発電所」の記事については、「ヴォルガ水力発電所」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2020/09/04 08:39 UTC 版)
「Temporal Key Integrity Protocol」の記事における「技術的詳細」の解説
TKIPおよび関連するWPA規格では、WEPで発生したセキュリティ問題への対策として3つのセキュリティ強化が実装されている。まずTKIPでは、秘密ルート鍵と初期化ベクトルを関数で混合してからRC4の初期化を行う。一方WEPでは、ルート鍵と初期化ベクトルを単に連結してRC4ルーチンに渡している。このため関連鍵攻撃に弱い。第二にWPAではシーケンスカウンタを実装し、リプレイ攻撃に対する防御を施している。アクセスポイントは順序外で受信したパケットを捨てる。最後に、TKIPにはMICHAELと呼ばれる64ビットメッセージ完全性チェックが実装されている。 既存のWEPハードウェアを少しアップグレードしただけで利用できるようにするため、TKIPはWEPと同じRC4を採用している。また、TKIPでは鍵再発行機構も提供している。TKIPではパケット毎にユニークな鍵を使っている。 鍵混合により、1つの鍵で暗号化されるデータ量が実質的に少なくなり、攻撃者が鍵を復号するための計算量を増大させている。また、WPAで実装しているメッセージ完全性チェック MICHAEL は、偽造パケットが受け入れられるのを防ぐ。WEPでは、暗号解読されていなくても、内容のわかっているパケットを修正することが可能だった。
※この「技術的詳細」の解説は、「Temporal Key Integrity Protocol」の解説の一部です。
「技術的詳細」を含む「Temporal Key Integrity Protocol」の記事については、「Temporal Key Integrity Protocol」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2019/03/27 06:33 UTC 版)
インターネットと同様の階層型アーキテクチャを採用している。基本的なパケット伝送機能 CIGALE が重要であり、信頼できない「データグラム」サービスを提供する。なお、datagram はルイ・プザンが data と telegram を合成して造った言葉である。パケット交換機がデータの正しい配送を保証する必要がないため、設計が大幅に簡略化された。 距離ベクトル型ルーティングプロトコルを採用しており、メトリックには様々なものを使って実験した。また、時刻同期プロトコルを備え、全パケット交換機の時刻を同期させていた。CIGALEには、あふれたパケットを捨てることで輻輳制御をするという初期の試みも含まれている。 CIGALEという名称(フランス語で「セミ」)は、開発者らが各コンピュータにスピーカーを設置し、そのコンピュータにパケットが到着したときにセミの鳴き声のような音を鳴らしたことに由来する (Gillies and Cailliau 2000:38)。 その上に構築されたエンドツーエンド・プロトコルは信頼性のあるトランスポート層サービスを提供し、さらにその上にアプリケーションが構築された。ユーザーから見える信頼できるデータ列の単位を letters と呼び、TCPの「信頼できるバイトストリーム」と対比される。トランスポート層プロトコルは順序を保証しない信頼できないデータグラムの配送も可能で、今では標準的機構となっている 端点間の肯定応答とタイムアウトを使用する。また、スライディングウィンドウやエンドツーエンドのフロー制御も備えていた。
※この「技術的詳細」の解説は、「CYCLADES」の解説の一部です。
「技術的詳細」を含む「CYCLADES」の記事については、「CYCLADES」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2020/12/27 03:31 UTC 版)
インテリジェント文書処理 (英:Intelligent Document Processing、IDP) と呼ばれる技術が急速に伸びてきている。これはインテリジェント・プロセス・オートメーション (IPA)の特定の形式であり、機械学習、自然言語処理またはインテリジェント文字認識 (ICR)などの人工知能技術を用いて、紙ベースの請求書、帳票、注文書、契約書などの非構造文書から情報を抜き出す手法である。
※この「技術的詳細」の解説は、「文書処理」の解説の一部です。
「技術的詳細」を含む「文書処理」の記事については、「文書処理」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/01/16 17:28 UTC 版)
「Counter mode with Cipher-block chaining Message authentication code Protocol」の記事における「技術的詳細」の解説
CCMPでは、データの機密保持のためのCTRと、認証および完全性の検証のためのCBC-MACを組み合わせたCCMモードを利用する。CCMPでは、MPDUのデータユニットとIEEE 802.11 MPDUヘッダの双方を保護する。共通鍵暗号にはAESが用いられ、鍵長およびブロック長はともに128ビットである。CCMPのCCMモードでは以下のパラメータが用いられる。 M = 8; MICは8オクテット. L = 2; フィールド長は2オクテット CCMPのMPDUは5つのセクションから構成される。1つ目は、データパケットの宛先と送信元のアドレスを含むMACヘッダである。2つ目は、8オクテットからなる、パケット番号 (PN)、初期化ベクトル (IV)、キーIDを含むCCMPヘッダである。PNは48ビットの番号であり6オクテットに格納される。PNは最初の2つおよび最後の4つのオクテットであり、パケットごとに増加する。PNの間に挟まれる形で予約オクテットとキーIDオクテットが配置される。キーIDオクテットは、初期化ベクトル (bit 5)、キーID (bits 6-7)、そして予約サブ領域 (bits 0-4) から構成される。CCMPはこれらの値をデータユニットとメッセージ認証符号の暗号化に用いる。3つ目はデータユニットであり、パケットで送信されるデータが含まれる。これら3つに、完全性の検出と認証のためのメッセージ認証符号 (MIC) と、誤り検出訂正のためのフレームチェックシークエンス (FCS) が加わる。これらのセクションのうち、暗号化されているのはデータユニットとMICのみである。
※この「技術的詳細」の解説は、「Counter mode with Cipher-block chaining Message authentication code Protocol」の解説の一部です。
「技術的詳細」を含む「Counter mode with Cipher-block chaining Message authentication code Protocol」の記事については、「Counter mode with Cipher-block chaining Message authentication code Protocol」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/03/17 14:11 UTC 版)
「ヴィカース (エンジン)」の記事における「技術的詳細」の解説
約40トンの非対称ジメチルヒドラジン(UDMH)を燃料として、四酸化二窒素(N2O4)を酸化剤として使用し、最大推力は725kNである。推力増強型の燃焼室の圧力は旧型の52.5 barに対して58.5 barに達し、推力は800 kNである。 前述のとおり、フランスのCNES/SEPによって開発されたバイキング 4Aの技術協力を受けている。 ヴィカースの第一の違いは燃焼時間が長い事である。
※この「技術的詳細」の解説は、「ヴィカース (エンジン)」の解説の一部です。
「技術的詳細」を含む「ヴィカース (エンジン)」の記事については、「ヴィカース (エンジン)」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2019/09/19 04:31 UTC 版)
LARCは、48ビットワード長の大型コンピュータである。二五進法を採用し、4ビットで1桁を表すので11桁の符号付数値を扱うことができる。命令は48ビット、つまり1ワードが1命令に対応している。各桁にパリティビットがあってエラー検出するため、実際には全体で60ビット(データ48ビット、パリティ用12ビット)となっている。基本構成で26本の汎用レジスタを持ち、最大99本の汎用レジスタを持つことができる。汎用レジスタのアクセス時間は1マイクロ秒である。 基本構成では1個の「コンピュータ」を持ち、2台目の「コンピュータ」を接続してマルチプロセッサ構成に拡張することができた。 「プロセッサ」は独立した装置(命令セットも「コンピュータ」とは異なる)であり、12~24台の磁気ドラムメモリ装置、4~40台の磁気テープ装置、2台の電子ページレコーダー、1~2台の高速プリンタ、1台の高速パンチカードリーダーを接続できる。 LARCでは、2500ワードの磁気コアメモリバンクを使用し、1台のメモリ筐体に4個のメモリバンクを格納する。基本構成では8バンク(メモリ筐体2台)であり、20000ワードとなる。最大構成は39バンク(10筐体)、97500ワードである。磁気コアメモリも桁毎のパリティビットをエラー検出のために持っており、1ワード60ビットである。磁気コアメモリのアクセス時間は8μ秒、サイクル時間は4μ秒である。各バンクは独立して操作され、ビジー状態でなければ任意のサイクル時間毎にアクセスを開始することができる。違うバンクにきちんとメモリアクセスが分散されるようにインターリーブアクセスすることで、全体としてスループットを4μ秒とすることができた(例えば、命令フェッチとデータアクセスを別々のバンクになるようプログラムを配置する)。 データ転送バスは2個の「コンピュータ」と1個の「プロセッサ」に接続され、コアメモリは多重化されてスループットを最大限に引き出している。4μ秒のバスサイクルは8つの500ナノ秒のスロットに分割され、以下のようにバスを使用する。このため基本構成で8バンクとなっている。 プロセッサ - 命令とデータ コンピュータ 1 - 命令 コンピュータ 2 - データ I/O DMA 同期機構 - データ 未使用 コンピュータ 2 - 命令 コンピュータ 1 - データ I/O DMA 同期機構 - データ 競合やデッドロックをなくし、システムの複数のセクション(「コンピュータ」、「プロセッサ」、I/O DMA 同期機構)による同一メモリバンクへの同時アクセスを避けるため、コアメモリシステムは優先度とインターロックを行う。あるメモリバンクにアクセスが発生すると、次の4μ秒のサイクル中はアクセスできない。その期間中に他のセクションがその同じメモリバンクにアクセスしようとした場合、それは次のサイクルまで待たされることになる(インターロック)。デッドロックを防ぎ、I/Oシステムのタイムアウトを防ぐため、以下のような優先度制御が行われる。 I/O DMA 同期機構 - 最高優先度 プロセッサ コンピュータ - 最低優先度 もし高い優先度のセクションがインターロックで4μ秒サイクル待たされるなら、次の4μ秒サイクルで再試行する間、他の低優先度のセクションはそのメモリバンクへの新たなアクセスができないよう制御される。
※この「技術的詳細」の解説は、「LARC」の解説の一部です。
「技術的詳細」を含む「LARC」の記事については、「LARC」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/05/16 21:56 UTC 版)
規格書はITU websiteから自由に入手可能であり、当該文書を権威あるリファレンスとして使用する必要がある。必須項目を以下に要約する。
※この「技術的詳細」の解説は、「Rec. 709」の解説の一部です。
「技術的詳細」を含む「Rec. 709」の記事については、「Rec. 709」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/05/17 02:22 UTC 版)
HDR10の定義は以下の通り: EOTF: SMPTE ST 2084(PQ) ビット深度:10ビット 原色色度:Rec.2020(Rec.2100の原色と同一) 静的メタデータ:SMPTE ST 2086(マスタリングディスプレイの色域体積)、MaxFALL、MaxCLL クロマ・サブサンプリング:4:2:0(圧縮映像源用) PQ10はPQ,10ビットおよびRec. 2100の原色色度を用い、一切のメタデータを有しないHDR形式を示す。 HDR10では、厳密に最大10,000cd/m2のピーク輝度に制限されているが、一般的なHDR10コンテンツは1,000~4,000cd/m2のピーク輝度でマスタリングされている。 HDR10はSDRディスプレイに対する後方互換性は有していない。 HDR10コンテンツよりも色域体積が小さなHDR10ディスプレイ(例えば、ピーク輝度の表示能力が低いなど)では、HDR10のメタデータがコンテンツを調整するのに役立つ。しかしながら、このメタデータは静的(映像全体で一定)であり、さらにどのように調整するべきかは示さないので、決定はディスプレイにまかされ、制作者の意図が再現される保証はない。 HDR10と競合する形式にはドルビー・ビジョン、HDR10+(それぞれのディスプレイで、シーンごとないしフレームごとの制作者の意図を維持するのを可能とする動的メタデータを提供する)およびHLG(SDRとのある程度の後方互換性を有する)がある。
※この「技術的詳細」の解説は、「HDR10」の解説の一部です。
「技術的詳細」を含む「HDR10」の記事については、「HDR10」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2019/09/27 07:29 UTC 版)
「UNIVAC 1103」の記事における「技術的詳細」の解説
UNIVAC 1103 は 1024ビットのウィリアムス管メモリを36本使用しており、1024ワード×36ビットのRAMを備えている。36本のウィリアムス管はそれぞれ直径5インチ(約13cm)であったという。また磁気ドラムメモリは 16,384ワードの容量を持つ。この静電メモリとドラムメモリには直接アドレスが振られている。アドレス 0~01777(八進数)には静電メモリが配置され、040000~077777(八進数)には磁気ドラムメモリが配置されている。 固定小数点数は 1ビットの符号と 35ビットの値からなり、負数は1の補数形式で表現する。命令は 6ビットの命令コードと 15ビットのオペランドアドレスからなる。 プログラミング言語としてはいくつかのアセンブラ(レミントン・ランド製の RECO、Ramo-Wooldridge Corporation の RAWOOP)と、いくつかの浮動小数点変換システム(Ramo-Wooldridge Corporation の SNAP、Consolidated Vultee Aircraft の FLIP、ライト・パターソン空軍基地で開発された CHIP)があった。
※この「技術的詳細」の解説は、「UNIVAC 1103」の解説の一部です。
「技術的詳細」を含む「UNIVAC 1103」の記事については、「UNIVAC 1103」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2015/05/08 08:22 UTC 版)
「フレモント・ストリート・エクスペリエンス」の記事における「技術的詳細」の解説
初めに建設されたディスプレイは、道路のキオスクに置かれた全32台のコンピューターによって制御される、210万個の電球が組み込まれたものであった。道路全体に設置されたスピーカーを用いた音響システムは、35万ワットの電力を消費していたと見積もられている。ディスコ・ナイトというイベント時には、付加的な娯楽としてストロボがいくつかの地点に設置された。 またディスプレイに「リアル」な画像を映し出すなど、新基軸となるものも取り入れた。新技術がディスプレイを湾曲させるまでに発達し、低解像度の画像も下から見ることができるようになった。この際、画像が不明瞭になるのを防ぐため、ディスプレイ全体で画像をゆっくりと動かすことで調整が行われた。 その後2001年の改良により、音響システムは55万ワットまでエネルギーを消費するようになった。また2004年に行われた改良では、ディスプレイに1250万個の発光ダイオードが使用され、それ以前に使用されていた電球中心のディスプレイよりも多くの色彩の組み合わせが表示できるようになった。さらに以前の制御のシステムは、10台のコンピューターを使用した中央制御室のものへ取って代わることになった。
※この「技術的詳細」の解説は、「フレモント・ストリート・エクスペリエンス」の解説の一部です。
「技術的詳細」を含む「フレモント・ストリート・エクスペリエンス」の記事については、「フレモント・ストリート・エクスペリエンス」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2020/06/05 08:00 UTC 版)
電子メールメッセージを配送するプロセスは、その内容を tmp ディレクトリに一意なファイル名のファイルとして書き込む。一意なファイル名を生成する現在のアルゴリズムは、時刻とホスト名といくつかの擬似乱数パラメータを使って一意性を保証している。 配送プロセスは、tmp/unique にファイルを作り、メッセージを書き込み、それを new/unique に移動させる。この移動は一般に new へのハードリンクを生成し、その後 tmp からアンリンクするという手順だが、実装によっては単に rename() を使っている。電子メールクライアントは tmp を決してみることは無いので、このような手順でMaildirを読んでいるプロセスが部分的に書かれたメッセージを読み取ってしまうという事態を避ける。 電子メールクライアントプロセスが new ディレクトリにメッセージを見つけると、それを cur に移動させる。このときは rename() を使う。リンクしてからアンリンクするという前述の方式をここで使うと、メッセージが両方に存在するという事態が生じる可能性がある。そして、中身を読む前にファイル名の末尾に付加情報を追加する。この付加情報は、まずコロンがあり(一意なファイル名と情報部分を区別するため)、次に '2' とコンマが1つずつあり、各種フラグが並ぶ。'2' は大まかに言えば、コンマの後の情報のバージョンを意味する。ただし、公式なバージョンとしては '2' しかなく、'1' は実験段階で使われただけである。仕様上定義されているフラグとしては、"P"、"R"、"S"、"T"、"D"、"F" がある。Dovecotでは小文字を26種類のIMAPキーワードに使い、それらには$MDNSentのような標準化されたキーワードやユーザー定義フラグが含まれる。
※この「技術的詳細」の解説は、「Maildir」の解説の一部です。
「技術的詳細」を含む「Maildir」の記事については、「Maildir」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/03/13 08:55 UTC 版)
「標準ダイナミックレンジビデオ」の記事における「技術的詳細」の解説
一つの画像で人間の視覚が受け取ることのできるダイナミックレンジは14段前後である。従来のガンマ・カーブと、サンプルあたり8ビットのビット深度を有するSDRビデオのダイナミックレンジは、5%の輝度閾値を用いると約6段を有する。(この論文では一般的なディスプレイが理想よりも暗いことを考慮して、標準的な2%ではなく、5%の閾値を採用している。)サンプルあたり10ビットのビット深度を有するプロ用SDRビデオでは約10段のダイナミックレンジを有する。従来のガンマ曲線はRec. 601およびRec. 709を含んでいる。従来のガンマ曲線の直線部分は低照度部分のカメラノイズを制限するために使用されたが、ハイダイナミックレンジ(HDR)カメラではもはや必要ではない。Rec. 601の従来のガンマ曲線の例を示す: E = { 4.500 L L < 0.018 1.099 L 0.45 − 0.099 L ≥ 0.018 {\displaystyle E={\begin{cases}4.500L&L<0.018\\1.099L^{0.45}-0.099&L\geq 0.018\end{cases}}}
※この「技術的詳細」の解説は、「標準ダイナミックレンジビデオ」の解説の一部です。
「技術的詳細」を含む「標準ダイナミックレンジビデオ」の記事については、「標準ダイナミックレンジビデオ」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/04/01 10:06 UTC 版)
砲身の長さは21口径長(L/21)であった。最大発射速度は毎分15発だが実際には毎分10発程度だった。 閉鎖器は垂直鎖栓式であり、後面が剥き出しになっている「Open Jaw」の鎖栓(breech block、ブリーチブロック)には、砲尾(薬室)に弾薬を装填するための穴が開いており、鎖栓が上方向にスライドして砲尾(薬室)の穴と鎖栓の穴をずらすことで、砲尾(薬室)を鎖栓で塞いで閉鎖する仕組みである(画像は閉鎖した状態)。 砲身の下側には駐退復座機が一本ある。 砲の左側面には直接照準器(眼鏡)が取り付けられ(画像では外されている)、砲手は砲の左側に位置して砲を操作する。 砲の左側面末尾にある板は、砲手を砲の後退(後座)から守るための危害防止(安全)板と、人力による砲の直接操作のための肩当てである。 鎖栓の穴の下側には、撃針(ファイアリング・ピン)式の点火装置があり、閉鎖状態において、その右横に撃鉄(ハンマー)が位置し、その下側には右手で握る銃把(グリップ)とレバー状の引き金(トリガー)があり、右水平方向に90度に起こされた撃鉄が、左水平方向に落ちて、鎖栓の点火装置を叩くことで、薬莢底部の雷管(プライマー)に点火し、発砲する。 本砲はフランス軽戦車の標準的な兵装であり、第一次世界大戦中のルノー FT-17 軽戦車、第二次世界大戦中ではルノー R35、オチキス H35 、H-38、FCM36などに装備されていた。また幾種類かのフランスの装甲車にも使用され、主にWhite-Laffly WL-50.に装備されていた。 ポーランド陸軍ではwz.18 ピュトー砲としてルノー FT-17 軽戦車やルノー R35、オチキス H35 などの軽戦車へ搭載され、またプジョー装甲車、Wz.28装甲車、Wz.29装甲車、Wz.34装甲車などに用いられた。また、一部のポーランド軍河川用舟艇や装甲列車などに使用された。
※この「技術的詳細」の解説は、「ピュトーSA18」の解説の一部です。
「技術的詳細」を含む「ピュトーSA18」の記事については、「ピュトーSA18」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/07/23 09:16 UTC 版)
物理層としては撚線対と電力線搬送通信が LonWorks 技術を含む各種標準規格で利用されている。また、LonWorks プラットフォームではIPトンネリング規格 EIA-852 を使って LonWorks ベースのネットワークとIPベースのネットワークの接続を行っている。LonWorks ベースの制御システムでは何らかのIPとの接続があることが多く、ユーザーインタフェースレベルや制御基盤にIPが使われる。 当初、エシェロンの設計した8ビットプロセッサ "Neuron chip" が LonTalk ノードを実装するのに不可欠であり、LonWorks ベースのハードウェアのほとんどで使われている。その後、汎用プロセッサでプロトコルを実装可能となった。しかし、まだ実際に使用された例は少ない。
※この「技術的詳細」の解説は、「LONWORKS」の解説の一部です。
「技術的詳細」を含む「LONWORKS」の記事については、「LONWORKS」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/07/15 13:33 UTC 版)
2011年末以来、入札に応じたドイツの造船企業はこの概念を提出している。この中で、サプライヤーごとが示す2、3の概念は船体形状やその他、連邦軍からの要求に応じている。 世界中で運用(公海、近海、沿岸水域)。 総ての気候(北極域と熱帯域)での使用。 26ノット以上の最大連続航行、巡航速度18ノット。シーステート4の状態まで対応。 補給無しで18ノット航行、4,000海里の航続力。 21日間連続洋上運用。 複合対ミサイル防衛(ASMD)、対空戦(AAW)および対水上戦闘(ASuW)、砲熕複合を伴う外周対応能力(海空標的に対する中型多目的チューブ体型武器、海空標的に対する軽銃砲2門、RAM Block 2を2基)、飛行およびデコイ(多機能ランチャー2基)、EMスペクトル全体をカバーする「合理的な全方位脅威検出器」(レーダー、赤外線、レーザー)。 中距離範囲の海上標的を正確に、段階的かつ選択的制御をする戦闘能力(ヘリコプター搭載)、 中型対艦ミサイル。 射程50kmのESSM中型艦対空ミサイル。 0.5~40GHz帯からの電子戦支援。 兵器発見能力 艦船管理領域・運用センター、弾薬庫防護、12.7x99mm NATO弾使用機関銃。 停泊中に使用する両舷および甲板用中央監視カメラ。 外隔壁・ハッチから全て開放可能なアクセス制御オプション(PIN/チップカード)。 想定気象条件下でのヘリコプターおよび無人機の全天候運用能力。 2年間の寿命要求(集中連続運用)低配員レベルに関する(最大140人+70人の将兵乗組能力)最大メンテナンス間隔での全システムの最高能力発揮状態を必要とする。焦点はライフサイクルコストの削減にあり一定の要件につながっている。 集中的な多目的運用を実現すべく、乗員は4ヶ月毎、96時間以内に交代する。 稼働期間と運転プロフィールがF125フリゲートと類似。 国内ワークショップとオンライン診断などの広範な修復機能(遠隔保守)によってモジュールは、推進能力と自己防護を担当する資材保全レベル3の乗員によって交換される。 洋上補給。 UAV(無人航空機)、UUV(無人水中艇)、USV(無人水上艇)およびヘリコプターの運用。 20フィートコンテナおよび コンポーネント格納場所。 医務室をはじめとする一般医療、救急医療および医療業務能力。 艦橋に追加できる監視能力(航海システム含む)、乗員の制御と被害極限、自働化。 無人航空機2機を搭載出来る施設、離陸重量15トンまでの甲板と艦載ヘリコプターのための格納庫と整備能力。 MKS180はモジュール式ミッションを前提に設計されており、その結果、艦は特定任務や業務パッケージの標準化された設備と乗員で構成される。MKS180の運用要求は2013年時点では、水中戦闘に焦点がおかれている。 艦自体が持つESMシステムを活用しての高度な教育システム(シギント)。 潜水艦に対する捜索と標的探査、特に戦術曳航ソナーシステム。 水中偵察や機雷戦、爆破装置を含むシステム、特に対機雷無人水中艇。 ダイバー圧力室。 ダイバーやフロッグマン検知システム。 艦は完全な技術的統合だけでなく、夜間や全天候型のアクセスおよび追加業務に対応できるよう、ペイロードが20フィートコンテナやミッションモジュールを必要としており、これは艦の設計に考慮される事項である。臨検・移乗コンポーネントは速力35ノットを超える硬式ゴムボート2隻を搭載し、同時に2個チームの特殊部隊が展開できる能力が求められている。
※この「技術的詳細」の解説は、「MKS180」の解説の一部です。
「技術的詳細」を含む「MKS180」の記事については、「MKS180」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/12/23 08:35 UTC 版)
「Component Object Model」の記事における「技術的詳細」の解説
COMコンポーネントにはクラスID (CLSID) が割り当てられ、COMコンポーネント同士はクラスIDによって区別される。CLSIDはGUIDで構成されている。各COMコンポーネントは1つ以上のインターフェイスを公開することで機能を提供している。インターフェイス同士はインターフェイスID (IID) で区別される。IIDもGUIDで構成されている。 COMインターフェイスはプログラミング言語とCOMとを結び付けている。COMコンポーネントへのアクセスは全てインターフェイスを通さなければならない。これによって、プロセスやコンピュータを跨いでCOMコンポーネントにアクセスすることができるようになっている(コンピュータを跨いでのアクセスにはDCOMが必要)。
※この「技術的詳細」の解説は、「Component Object Model」の解説の一部です。
「技術的詳細」を含む「Component Object Model」の記事については、「Component Object Model」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/12/24 07:42 UTC 版)
「Apple Newton」の記事における「技術的詳細」の解説
Newtonには、NewtonScriptと呼ばれる先進的なオブジェクト指向プログラミングシステムが用いられていた。これはAppleのウォルター・スミス (Walter Smith) が開発した。プログラム開発者たちの不満の種であったのは、このToolboxプログラミング環境が1000ドル以上もした点であった(後にこのプログラミング環境は無料で利用できるようになった)。さらに、この環境を使うには新しいプログラミング手法の習得が必要であった。にもかかわらず、多くのサードパーティーアプリケーションやシェアウェアアプリケーションがNewtonで使えるようになっていった。NewtonのデータはSoup(英語版)と呼ばれるデータストレージに保存され、格納された一つのデータをあらゆるアプリケーションで利用することが可能であった。そのためユーザーは自分で入力する項目を極力少なくすることができた。ほとんどのデータは「保存」という作業なしで保存されまさに紙のメモに書くような感じで入力できた。 MessagePadはMacintoshの標準シリアルポート規格である、丸いミニDIN8ピンコネクタを使っていた。これはより普及しているDB-9規格のものとは違っていた。MessagePad 2000と2100は独自の小さいフラットコネクタを備えており、変換ケーブルでつながるようになっていた。さらに、全機種に赤外線通信装置もついていた。Palmとは異なり、すべてのMessagePadには標準PCMCIA拡張スロットが装備されていた。(2000型と2100型は二つ装備)ハードウエア的にはPCMCIAのコネクターを持つがソフトウエア的な互換性は低かった、これはPCMCIAの規格が固まる前にリリースをしてしまったためである。これにより、専用のモデムやイーサネット接続環境さえも用意された。IEEE 802.11b無線LANカードや、ATA方式のフラッシュメモリーカード(一般的なコンパクトフラッシュフォーマットを含む)などのためのデバイスドライバがNewton利用者たちによって書かれた。1xxシリーズではオプションのキーボードがつなげられるようになっており、2x00型でもドングルを使って接続することができた。Newtonは電話番号のダイヤルトーンをMessagePadのスピーカーで鳴らすことができるようになっており、受話器をスピーカーのそばに持ってゆくことにより電話をかけることができた。また、この電話をかけたときにもログが記録されており、カレンダーでの記録を元に一日の行動を把握することができた。このほかオペレーティングシステム上でファクシミリや電子メールがサポートされていた(この場合、純正のモデム(8pinコネクター経由)もしくはMegahertz等のPCMCIAモデムカードが必要であった)。 MessagePad 2000と2100は、進化した手書き認識システム、160MHzのARMプロセッサ、Newton2.1、バックライト付きスクリーンを搭載していた。 MessagePadはスクリーンを横長(ランドスケープ状態)にも縦長(ポートレート状態)にも使うことができた。設定を変更すれば簡単に表示内容を90度回転させることができ、手書き入力も問題なく動作した。 Appleやサードパーティーメーカーは、クレジットカードや運転免許証、名刺、現金などとともにMessagePadを安全に持ち運べるケース(袋)を発売していた。これらのケースはMessagePad本体よりもさらに大きく、ポケットに収まるようなものではなかったため、主に衝撃や傷から守るためのものとして用いられることが多かった。 小さな着脱式のシリアルキーボードがあった。
※この「技術的詳細」の解説は、「Apple Newton」の解説の一部です。
「技術的詳細」を含む「Apple Newton」の記事については、「Apple Newton」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2020/09/23 08:13 UTC 版)
PHIGSの名に含まれる「hierarchical(階層的)」という言葉は、その特筆すべき1機能を表している。一般的なグラフィックスシステムとは異なり、PHIGSはシーングラフシステムを基礎標準の部分として含んでいる。モデルはCentralized Structure Store(CSS)と呼ばれる、描画プリミティブとそれらの属性(色、線スタイルほか)を含む「ワールド」を保持するデータベースにおいて構築される。PHIGSは抽象化されたワークステーションとして振る舞い、CSSは複数の表示領域において共有できる。 PHIGSを使って画面にグラフィックスを表示するには3つの手順を踏む。まずCSS内にモデルを構築し、次に抽象ワークステーションを作成して開き、最後にモデルを抽象ワークステーションに関連づける。ワークステーションはモデルを即時にレンダリングし、将来に渡ってモデルに加えられた変更はワークステーションの表示領域へ即座に反映される。 オリジナルのPHIGSは照明されたシーンをレンダリングする能力を欠いており、PHIGS+へと改められた。PHIGS+は基本的に同様の作法で動作するが、3次元シーンを照明する手段が加えられており、冗談半分にPHIGS PLUS("Plus Lumière Und Shading")とも呼ばれている。PHIGS+ではNURBS曲面のようなより高度なグラフィックスプリミティブも加えられている。
※この「技術的詳細」の解説は、「PHIGS」の解説の一部です。
「技術的詳細」を含む「PHIGS」の記事については、「PHIGS」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2012/12/04 00:25 UTC 版)
桁上げ保存ユニットは個の全加算器で構成され、それぞれは入力された3個の数の対応するビットのみに基づいて、単一の和と桁上げのビットを計算する。3個のビットの数 a, b, c があるとき、このユニットは部分和 ps とシフト桁上げ sc を生成する: 全体の和は次のように計算される: 桁上げ列 sc を1ビット左シフトする。 部分和列 ps の先頭(最上位ビット)に0を付け加える。 桁上げ伝播加算器(順次桁上げ加算器)を用いてこれらを加算し、結果の ビットの値を生成する。 3個以上の数を加算するとき、桁上げ保存加算器の後に桁上げ伝播加算器を用いる方法は、桁上げ伝播加算器を二つ用いる方法より高速である。これは、桁上げ伝播加算器では、前の桁上げビットが生成されるまで和ビットを計算できず、そのため個の全加算器の遅延に相当する遅延があるためである。これに対して、桁上げ保存加算器は、その出力値をすべて並列に生成し、そのため単一の全加算器と同じ遅延しかもたない。したがって、桁上げ保存加算器と桁上げ伝播加算器の合計の計算時間は(全加算器の遅延を単位として)であるのに対して、桁上げ伝播加算器2個ではとなる。
※この「技術的詳細」の解説は、「桁上げ保存加算器」の解説の一部です。
「技術的詳細」を含む「桁上げ保存加算器」の記事については、「桁上げ保存加算器」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2020/06/20 15:56 UTC 版)
共有ライブラリ内部でのプロシージャ呼び出しは一般に小さなプロシージャ・リンク・テーブルのスタブを通して行い、そこから実際の関数を呼び出す。これにより、共有ライブラリが以前にロードされていた別のライブラリ群からの関数呼び出しを引き継ぐことを可能にしている。 位置独立コードからデータを参照する場合はさらに間接的な方式となり、そのコードがアクセスする全グローバル変数のアドレスを格納したGOT (Global Offset Table) を使用する。コンパイル単位またはオブジェクトモジュールごとにGOTがあり、コードから見て固定の相対位置に置かれる(ただし、ライブラリをリンクするまで実際のオフセットは不明である)。リンカがモジュール群をリンクして共有ライブラリを作る場合、各モジュールのGOTをマージし、最終的なコードとのオフセット値を設定する。共有ライブラリをロードした後は、オフセット群を調整する必要はない。 位置独立関数がグローバルなデータにアクセスする際、その時点のプログラムカウンタの値からGOTの絶対アドレスを決定する。そのため、偽の関数呼び出しを行ってリターンアドレスをスタック上に得る技法(x86の場合)や、(特定の汎用レジスタに特別な意味を与える規約を設けるなど)特別なレジスタを使う場合(PowerPC、SPARC、MIPSなどのRISCプロセッサやESA/390など)がある。MC68000、MC6809、WDC 65C816、クヌースのMMIX、ARM、x86-64 といったプロセッサアーキテクチャでは、プログラムカウンタ相対でデータを参照できる。その場合は位置独立コードを小さくでき、レジスタもあまり使わずに済むので、より効率的となる。
※この「技術的詳細」の解説は、「位置独立コード」の解説の一部です。
「技術的詳細」を含む「位置独立コード」の記事については、「位置独立コード」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2020/08/06 21:32 UTC 版)
24行80桁のテキスト端末を入出力に使って動作する。最初のバージョンではファイル間のハイパーリンクが可能だった。Pascalで書かれており、Norsk Data(ノルウェーのコンピュータ企業)製コンピュータNORD-10上で動作した(OSはSINTRAN III)。バージョン2は、MS-DOSとVAX/VMSに移植されている。
※この「技術的詳細」の解説は、「ENQUIRE」の解説の一部です。
「技術的詳細」を含む「ENQUIRE」の記事については、「ENQUIRE」の概要を参照ください。
技術的詳細
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2018/04/24 00:49 UTC 版)
Icecastサーバはストリーミングコンテンツとして、HTTP上のVorbis、Opus、Theora、WebMや、SHOUTcastが使うプロトコル上のMP3、AAC、SHOUTcastプロトコル上のNSVを扱う。ストリーム源である外部プログラムを「ソースクライアント」と呼び、Icecastプロジェクトでは IceS の名称でソースクライアントプログラムも開発している。ソースクライアントとIcecastサーバは、通常別の場所で動作する(ソースクライアントは例えばスタジオで利用し、サーバは高帯域幅が利用可能なデータセンターなどに配備する)。 Nullsoft製のプロプライエタリなメディアサーバSHOUTcastと似たような機能を持つ。
※この「技術的詳細」の解説は、「Icecast」の解説の一部です。
「技術的詳細」を含む「Icecast」の記事については、「Icecast」の概要を参照ください。
Weblioに収録されているすべての辞書から技術的詳細を検索する場合は、下記のリンクをクリックしてください。
全ての辞書から技術的詳細を検索
- 技術的詳細のページへのリンク