設計上の問題

ウィキペディア小見出し辞書

設計上の問題

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/06/16 01:39 UTC 版)

「T-34」の記事における「設計上の問題」の解説

大きさが限られている問題について、傾斜した装甲を用いるということは全体的な容積の減少に加え、デッドスペースが増えることで利用可能容積を減らすことになる。前面の傾斜は前方にいる操縦手や機銃手に影響を与え、側面の傾斜は装備面での制限をもうける要因となった。これにより大小さまざまな運用上の影響を与えた。 低いシルエットの砲塔は防御の点においては有利だが、居住性が悪く、砲弾が床下に収納されていたので砲塔バスケットは採用されていなかった。特に1940/41年型では砲塔内が狭いため主砲を操作するハンドルは腕を交差させて回すという使いにくい配置であった。この問題は1942/43年型砲塔で改善された。砲塔における2人・3役（車長・砲手・装填手）体制と戦車長の非独立性については、3名用大型砲塔を採用したT-34-85で解消された。 ディーゼルエンジンはガソリンエンジンに比べサイズが大きく、車体サイズに占めるエンジン/変速機スペースが大きくなり、同時代のほぼ同サイズのⅣ号戦車やM4中戦車に比べて乗員の居る戦闘室のスペースは狭かった。 主砲の俯角がほとんどつけられず、近距離においては背の低い対戦車砲や突撃砲、歩兵のパンツァーファウストなどに対抗できなかった。また車体前方機銃の視界や射界は狭く、あまり効果的ではなかったという。 シンプルな乾式クラッチ・ブレーキ式操行装置は、生産と整備が楽である反面、特に前期の4段変速型は操作が大変重く操縦手を疲労させる。片腕の力だけでは動かせず、同時に片膝で押しながら動かさなくてはいけないほどだった。長時間の行軍の際は、隣の無線手がギアチェンジの時に手を貸してやったほどであり、疲労で体重が2～3 kg も減るとまで言われた。特にバックに入れる時はハンマーでレバーを打撃して入れたという証言もある。また直進速度は確かに速いが、構造的に左右に細かく機動するのは苦手で、大回りになりがちであった。高速走行しながら滑らかに曲がるという機動は不可能である。更にクラッチ接続のタイミングも難しく、性急な操作により破損する危険も大きかった。しかしこれは、ドイツ戦車同様にシンクロメッシュ機構を取り入れた5段変速型の登場により、かなり改善されている。 排気管にマフラーの類は無く、ディーゼルエンジンはラバーマウントを介さず直接車体に固定され振動と騒音がひどい。また、下向きの排気管により乾燥した場所では激しく土埃が発生する。 ディーゼルエンジンは炎上し難いというふれこみで採用され、事実乗員もそう考えていたが、実際の統計ではガソリンエンジンの戦車に比べ、燃料の爆発はおこさないまでも特に燃えにくいということはなかった。確かにガソリンエンジンと比較すると漏れとそれに対して火炎瓶などによる攻撃に対しては軽油・ディーゼルエンジンは安全であったといえる。しかしながら、徹甲榴弾のような対戦車火器による攻撃では容易に着火したし、一度炎上すると砲弾の誘爆をおこしやすく、乗員は直ちに退避する必要があった。朝鮮戦争では、T-34-85の乗員の死因の実に75パーセントが車輌火災による。 ラジエーターが虚弱で、被弾や衝撃で簡単に冷却水漏れをおこしやすく、またエアフィルターの性能が低く塵を除去しきれず、エンジンの寿命を縮めている。

設計上の問題

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/02/11 07:31 UTC 版)

「ヴァルカンエンジン」の記事における「設計上の問題」の解説

バルカン1と2の最大の違いは直径4×6mm、厚さ0.6mmの288本の円管で構成されている冷却ノズルである。溶接部の数の減少は、生産時間を13から5週間に短縮し、製造コストを低減した。しかし、アリアン5のフライト157の打ち上げ失敗の原因は、この新規性であるとされている。 認定試験中、冷却管に亀裂が生じていたが、それらは必要な品質基準を満たしているとして修復されてしまった。実際の飛行条件のみ、この型のロケットエンジンの深刻な設計上の問題を顕在化することができた。そして、アリアン5のフライト157でこれらの亀裂が再び発生し、その後のノズルの壁に穴を開けた座屈現象の出現につながった。ノズルが耐えることができる熱的および動的荷重は高かったが、シミュレーションでは、地上テスト中にそれらを検出することができなかった。 この事故の後、打ち上げの失敗の原因を究明した調査委員会は、アリアンスペース社にヴァルカン2のエンジンの製造の品質を向上させるだけでなく、これまでのヴァルカン1での経験に基づいて冷却システムを変更する事を勧告した。 また2011年3月30日のアリアン5 ECAの起動時に障害があり、安全上EAPは点火されず、打ち上げは延期された。その後、4月22日に無事に打ち上げられた。

設計上の問題

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/07/23 17:55 UTC 版)

「スタジアム」の記事における「設計上の問題」の解説

競技によって必要となるフィールドの大きさや形が異なる。一つの競技向けのスタジアムもあれば、複数の競技に対応できるものもある。各種フットボール専用のスタジアムは極めて一般的にみられる。多目的スタジアムで最も一般的なものはフットボール競技場と競争用のトラックを組み合わせたタイプで、若干の問題点はあるがおおむね良好に用いられる。最も大きな問題はフットボールの際に（特にフィールドの両端で）観客席が遠くなることである。小さなスタジアムでは両端部に観客席をおかないこともある。全周に観客席をもつスタジアムの平面形は楕円に、一端が開放されているタイプでは馬蹄形になる。特にアメリカ合衆国の学生フットボール会場ではこれら三種類はいずれも一般的である。 観戦するための屋外競技としては、アメリカ合衆国ではアメリカンフットボール（以下アメフト）と野球の人気が高い。そのため、特に1960年代に多くのアメフト・野球兼用のスタジアムが建設された。その中にはうまくいったものもあるが、両競技が要求するものにははっきりした違いがあるため、専用スタジアムを建設する動きが1972-1973年にカンサスシティーから始まり、特に1990年代よりその動きが加速していった。大リーグ用の野球場に隣接してNFL用のフットボールスタジアムを建設したケースは、かつては前述のカンサスシティー(カウフマン・スタジアムとアローヘッド・スタジアム)などごく一部にしか見られなかったが、近年ではアメフト・野球兼用のスタジアムに併設された広大な駐車場にアメフト・野球専用の球場をそれぞれ建てることにより、両球場が隣接する、あるいは同じ敷地内に両方の球場が配置されるケースは増加傾向にある(シアトル、フィラデルフィア、ピッツバーグ、シンシナティなど)。 多くの場合、古い野球場は既にある土地や都市の一角の平面形に合う形で建設されたので、フィールドの形が非対称になっていた。例えばヤンキースタジアムはニューヨーク、ブロンクスの一角にあった三角形の土地に建設されたので、左翼側は広いが右翼側は狭いという特徴をもつことになった。 農作物を段をなして植えた状態をさす「テラス」が、特にイングランドのスタジアムでは観客席をさす言葉として用いられることがある。イングランドではかつて殆どのスタジアムに見られ、アメリカの野球場でも時折みられる。これはtier という単語の代わりに用いられるものである。本来は立見席を意味していたが、現在では椅子が備えられているのが通例である。 正確に同じではないが関連した用法として、「テラス」が外野側の傾斜面を指すことがある。これは実用上ないし装飾上の目的を持っており、観戦に使うこともできる。オハイオ州シンシナティのクロスリー・フィールドのものが有名である。 スタジアムの設計が悪いと、ヒルズボロの悲劇（イングランドのシェフィールド・ヒルズボロ・スタジアムで1989年4月15日に起きた大規模な観客圧死事故。詰め掛けた観客とフェンスの間に挟まれた96人が死亡した）や ヘイゼルの悲劇（ベルギーのブリュッセル・エゼル競技場で1985年5月29日に起きた事故。イングランドの流儀でどっと押し寄せたリヴァプール側ファンに驚いたユヴェントゥス側ファンが混乱状態に陥り、39人が死亡した）のような大事故に結びつくことがある。 サッカースタジアムにおいては、FIFA（国際サッカー連盟）の規定ではスタンド最前列からタッチラインまでの距離は8.5mが目安とされているというが、それ以下のスタジアムもある。

設計上の問題

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/06/22 13:55 UTC 版)

「ソフトウェアエージェント」の記事における「設計上の問題」の解説

エージェントベースのシステムの開発する際の興味深い問題として、以下のようなものが挙げられる。 タスクのスケジューリングと同期をどのように実現するか エージェントがどうやってタスクの優先順位付けをするか エージェント間の協調動作やリソース確保をどうするか エージェントをどのように別の環境に生成するか、内部状態をどう保持するか 周囲の環境をどのようにして感知し、環境の変化を動作の変化に結びつけるか 通信をどう行うか エージェント群の階層構造はどうすべきか（例えば、タスク実行エージェント、スケジューリングエージェント、リソース確保エージェント……） ソフトウェアエージェントが効率的に協調動作するには、データの意味論的要素を共有しなければならない。これはコンピュータシステムがメタデータを提示することで可能である。 「エージェント処理; agent processing」には相互に関連する以下の2つの定義がある。 内部状態処理と知識表現のためのオントロジー 協調動作のプロトコル - タスク間の通信を行うための標準 エージェントシステムは実世界を並行性や並列性でモデル化したものでもある。 Agent Machinery - 各種エンジン。知能程度は様々である。 Agent Content - Machinery が推論や学習に利用するデータ。 Agent Access - Machinery が Content を把握し推論の結果として行動することを可能にする方法 Agent Security - 分散コンピューティングに関連した懸念の中でも特にエージェントに関して指摘されている問題 エージェントはアクセス手段を用いてローカルまたはリモートのデータベースを調べ、Content となるものを探す。アクセス手段としては、ネットニュースをエージェントが受け取れるようにするとか、掲示板を用意するとか、ウェブを歩き回る機能を使用したりする。あらゆる情報源を検索できるわけではないので、このようにして検索される Content は部分的にフィルタリングされているだろう。エージェントはさらに詳細な検索を行ったり、機械的言語処理を行ってキーワードやサインを Content から探し出す。この要約された Content （またはイベント）がエージェントの推論機構(Machinery)に渡され、新たな Content に対して何をすべきかを判断する。この過程でイベント Content はユーザーが提供したルールベースか知識内容と結合する。その過程で新たな Content から良い一致を検出したら、エージェントは Machinery の別の機構を使ってさらに詳細な検索を行う。最終的に、エージェントは新たな Content に基づいて採るべき行動を決定する。例えば、ユーザーに対して重要なイベントが発生したことを通知する。この行動はセキュリティ機能によって検証された後、ユーザーの権限を与えられる。エージェントはユーザーアクセス手段を使ってメッセージをユーザーに提供する。ユーザーがそのイベントが重要であり、素早く対応すべきと判断したら、エージェントの学習機能(Machinery)がその重み付けを更新し、今後の同種のイベント発生に備えることもできるだろう。