システムエンジニアリング

システムエンジニアリングの手法は、プリント基板設計、ロボット工学、橋梁建設、ソフトウェア統合、宇宙船設計といった複雑なプロジェクトで活用されています。システムエンジニアリングでは、モデリングとシミュレーション、要件分析、スケジューリングといった様々なツールを用いて、複雑なプロジェクトを管理します。

システムエンジニアリングは、複雑なシステムをそのライフサイクル全体にわたって設計、統合、管理する方法に焦点を当てた、工学と工学管理の学際的な分野です。システムエンジニアリングの中核は、システム思考の原則を用いて、この知識体系を体系化することです。こうした取り組みの成果であるエンジニアリングシステムは、相乗効果を発揮し、集合的に有用な機能を果たすコンポーネントの組み合わせとして定義できます。

要件エンジニアリング、信頼性、ロジスティクス、さまざまなチームの調整、テストと評価、保守性など、システムの設計、開発、実装、そして最終的な廃止を成功させるために必要な多くの分野（いわゆる「スキル」）は、大規模または複雑なプロジェクトを扱う際にはより困難になります。システムエンジニアリングは、そのようなプロジェクトにおける作業プロセス、最適化手法、およびリスク管理ツールを扱います。システムエンジニアリングは、産業工学、生産システム工学、プロセスシステム工学、機械工学、製造工学、生産工学、制御工学、ソフトウェア工学、電気工学、サイバネティクス、航空宇宙工学、組織研究、土木工学、プロジェクト管理など、技術的かつ人間中心の分野と重複しています。システムエンジニアリングは、プロジェクトまたはシステムのあらゆる可能性のある側面が考慮され、全体に統合されることを保証します。

システムエンジニアリングプロセスは、製造プロセスとは全く異なる発見プロセスです。製造プロセスは、最小限のコストと時間で高品質な成果物を実現する反復的な活動に重点を置いています。システムエンジニアリングプロセスは、解決すべき真の問題を発見し、発生する可能性が最も高い、あるいは最も影響の大きい故障を特定することから始めなければなりません。システムエンジニアリングは、これらの問題に対する解決策を見つけることに関わっています。

歴史

エンタープライズ製品開発プロセスの品質機能展開（QFD）

システムエンジニアリングという用語は、1940年代のベル電話研究所にまで遡ります。 [ 1 ]システム全体の特性を特定し操作する必要性は、複雑なエンジニアリングプロジェクトでは、各部分の特性の合計とは大きく異なる場合があり、特に米国軍のシステムを開発しているさまざまな業界がこの分野を適用する動機となりました。[ 2 ] [ 3 ]

システムの改善を設計の進化に頼ることができなくなり、既存のツールでは増大する需要に対応できなくなったため、複雑さに直接対処する新しい手法が開発され始めました。[ 4 ]システムエンジニアリングの継続的な進化は、新しい手法とモデリング技術の開発と特定で構成されています。これらの手法は、エンジニアリングシステムが複雑化するにつれて、その設計と開発管理をより深く理解するのに役立ちます。システムエンジニアリングの分野でよく使用される一般的なツール、例えば汎用システム言語（USL）、統一モデリング言語（UML）、品質機能展開（QFD）、統合定義（IDEF）などは、この時期に開発されました。

1990年、システムエンジニアリングの専門団体である全米システムエンジニアリング評議会（NCOSE）が、米国の複数の企業や団体の代表者によって設立されました。NCOSEは、システムエンジニアリングの実践と教育の改善の必要性に応えるために設立されました。米国以外のシステムエンジニアの参加が増えた結果、1995年に組織名称は国際システムエンジニアリング評議会（INCOSE）に変更されました。 [ 5 ]いくつかの国では、システムエンジニアリングの大学院プログラムが提供されているほか、現役エンジニア向けの継続教育オプションも提供されています。[ 6 ]

コンセプト

いくつかの定義
現代システム工学の創始者ともいわれるサイモン・ラモは、この分野を次のように定義しました。「…部分とは区別して全体の設計と応用に重点を置き、問題を全体として捉え、あらゆる側面とあらゆる変数を考慮し、社会と技術を結び付ける工学の一分野。」 [ 7 ] — Conquering Complexity、2005年。
「成功するシステムの実現を可能にする学際的なアプローチと手段」[ 8 ] — INCOSEハンドブック、2004年。
システムエンジニアリングとは、システムの設計、構築、運用に対する堅牢なアプローチです。簡単に言えば、このアプローチは、システム目標の特定と定量化、代替システム設計コンセプトの作成、設計トレードの実施、最適な設計の選択と実装、設計が適切に構築され統合されていることの検証、そして実装後のシステムが目標をどの程度達成しているか（または達成したか）の評価から構成されます。[ 9 ] — NASAシステムエンジニアリングハンドブック、1995年。
「システム全体、生命全体の原理を用いて効果的なシステムを作る芸術と科学」または「複雑な問題や課題に最適なソリューションシステムを作る芸術と科学」[ 10 ] —デレク・ヒッチンズ、システム工学教授、INCOSE（英国）元会長、2007年。
「工学的観点からのこの概念は、工学科学者（すなわち、幅広い視野を持つ科学のジェネラリスト）の進化である。その方法はチームアプローチである。大規模システムの問題に対して、科学者とエンジニア、ジェネラリストとスペシャリストからなるチームが共同で解決策を見つけ、それを物理的に実現するために尽力する…この手法は、システムアプローチやチーム開発法など、様々な名称で呼ばれてきた。」[ 11 ] —ハリー・H・グッド＆ロバート・E・マコール、1957年。
システム工学の手法は、各システムが多様で特殊な構造とサブ機能から構成されているにもかかわらず、統合された全体であると認識しています。さらに、あらゆるシステムには複数の目的があり、それらの間のバランスはシステムごとに大きく異なる可能性があることを認識しています。この手法は、重み付けされた目的に応じてシステム全体の機能を最適化し、各構成要素の最大限の互換性を実現することを目指しています。[ 12 ] —ハロルド・チェスナット著『システム工学ツール』、1965年。

システム工学は、工学におけるアプローチの一つであり、近年では学問分野の一つとして捉えられています。システム工学教育の目的は、様々なアプローチを簡潔に体系化し、その過程で他の工学分野と同様の新たな手法や研究機会を見出すことです。システム工学は、アプローチとして全体論的かつ学際的な特質を有しています。

起源と伝統的な範囲

伝統的なエンジニアリングの範囲は、物理システムの構想、設計、開発、製造、運用を網羅しています。システムエンジニアリングは、本来の意味で、この範囲に含まれます。この意味での「システムエンジニアリング」とは、エンジニアリングコンセプトの構築を指します。

より広い範囲への進化

「システムエンジニア」という用語の使用は、時とともに進化し、「システム」とエンジニアリングプロセスという、より広範で包括的な概念を包含するようになりました。この定義の進化は継続的な議論の対象となっており[ 13 ]、この用語は狭義と広義の両方の分野に適用され続けています。

従来のシステム工学は、古典的な意味での工学の一分野、つまり宇宙船や航空機といった物理システムにのみ適用されるものとして捉えられていました。近年、システム工学は、特に人間がシステムの不可欠な構成要素とみなされるようになった際に、より広い意味を持つようになりました。例えば、ピーター・チェックランドは、「エンジニアリング」という言葉は「一般的な意味で解釈できる。会議や政治的合意をエンジニアリングすることもできる」と述べ、システム工学のより広い意味を捉えています。[ 14 ] : 10

システムエンジニアリングのより広い範囲に合わせて、システムエンジニアリング知識体系（SEBoK）[ 15 ]では、3つのタイプのシステムエンジニアリングを定義しています。

  • 製品システム エンジニアリング (PSE) は、ハードウェアとソフトウェアで構成される物理システムの設計に重点を置いた従来のシステム エンジニアリングです。
  • エンタープライズ システム エンジニアリング (ESE) は、エンタープライズ、つまり組織または組織の組み合わせをシステムとして捉える考え方です。
  • サービスシステムエンジニアリング（SSE）は、サービスシステムのエンジニアリングに関係しています。チェックランドは、サービスシステムを、他のシステムにサービスを提供するものとして考えられたシステムと定義しています。[ 14 ]ほとんどの土木インフラシステムはサービスシステムです。

全体論的視点

システムエンジニアリングは、開発サイクルの早い段階で顧客のニーズと必要な機能を分析し、抽出し、要件を文書化し、その後、システムライフサイクル全体を考慮しながら設計統合とシステム検証を進めることに重点を置いています。これには、関係するすべての利害関係者を完全に理解することが含まれます。オリバーらは、システムエンジニアリングのプロセスは以下のように分解できると主張しています。

  • システムエンジニアリングの技術プロセス
  • システムエンジニアリング管理プロセス

オリバーのモデルでは、管理プロセスの目標はライフサイクルにおける技術的取り組みを組織化することであり、技術プロセスには利用可能な情報の評価、有効性測定の定義、動作モデルの作成、構造モデルの作成、トレードオフ分析の実行、および順次ビルド＆テスト計画の作成が含まれます。[ 16 ]

業界では用途に応じて様々なモデルが用いられていますが、いずれも前述の様々な段階間の関係性を特定し、フィードバックを取り入れることを目的としています。このようなモデルの例としては、ウォーターフォールモデルやVEEモデル（Vモデルとも呼ばれる）などが挙げられます。[ 17 ]

学際分野

システム開発には、多くの場合、多様な技術分野からの貢献が求められます。[ 18 ]開発作業のシステム（全体論的）視点を提供することで、システムエンジニアリングは、すべての技術貢献者を統一されたチームワークへと導き、構想から生産、運用、そして場合によっては終了・廃棄に至るまでの構造化された開発プロセスを形成します。調達においては、全体論的統合分野は貢献を組み合わせ、コスト、スケジュール、性能間のトレードオフのバランスを取りながら、製品のライフサイクル全体にわたって許容可能なリスクレベルを維持します。[ 19 ]

この考え方は教育プログラムでもよく取り入れられており、システム工学のコースは他の工学部の教員によって教えられ、学際的な環境を作り出すのに役立っています。[ 20 ] [ 21 ]

複雑さの管理

システムエンジニアリングの必要性は、システムやプロジェクトの複雑性の増大に伴い高まりました。その結果、コンポーネント間の摩擦の可能性が飛躍的に高まり、設計の信頼性が低下しました。この文脈において、複雑性にはエンジニアリングシステムだけでなく、人間によるデータの論理的構成も含まれます。同時に、システムは規模の拡大、データ量、変数、設計に関係するフィールド数の増加によって、より複雑になることがあります。国際宇宙ステーションは、そのようなシステムの一例です。

国際宇宙ステーションは、システムエンジニアリングを必要とする非常に複雑なシステムの一例です。

よりスマートな制御アルゴリズムの開発、マイクロプロセッサの設計、環境システムの分析などもシステム工学の領域に含まれます。システム工学では、システムの複雑性をより深く理解し、管理するためのツールや手法の活用が推奨されます。これらのツールの例をいくつかご紹介します。[ 22 ]

工学システムへの学際的なアプローチは、システムコンポーネントの挙動や相互作用が必ずしも明確に定義・理解できるとは限らないため、本質的に複雑です。このようなシステムやサブシステム、そしてそれらの相互作用を定義し、特徴づけることは、システムエンジニアリングの目標の一つです。これにより、ユーザー、オペレーター、マーケティング組織からの非公式な要件と技術仕様の間に存在するギャップをうまく埋めることができます。

範囲

システムエンジニアリング活動の範囲

[ 23 ]

システム工学の原則（全体論、創発的行動、境界など）は、システム思考があらゆるレベルで採用されている限り、複雑なシステムであろうとなかろうと、あらゆるシステムに適用できます。[ 24 ]防衛・航空宇宙産業以外にも、多くの情報技術系企業、ソフトウェア開発会社、電子通信分野の産業では、チームの一員としてシステムエンジニアを必要としています。[ 25 ]

INCOSEシステムエンジニアリングセンターオブエクセレンス（SECOE）の分析によると、システムエンジニアリングに費やされる最適な労力は、プロジェクト全体の労力の約15～20%であることが示されています。[ 26 ]同時に、システムエンジニアリングは本質的にコスト削減をはじめとする様々なメリットをもたらすことが研究で示されています。[ 26 ]しかし、近年まで、幅広い業界を対象としたより大規模な定量調査は行われてきませんでした。システムエンジニアリングの有効性を明らかにし、そのメリットを定量化するための研究が進行中です。[ 27 ] [ 28 ]

システム工学では、システムとその相互作用に関する仮定や理論を検証するためにモデリングとシミュレーションの使用を推奨しています。 [ 29 ] [ 30 ]

安全工学では、起こりうる故障を早期に検出できる手法が設計プロセスに組み込まれています。同時に、プロジェクトの開始時に下した決定の結果が明確に理解されていない場合、システムの寿命の後半に多大な影響を及ぼす可能性があり、これらの問題を調査し、重要な決定を下すのが現代のシステムエンジニアの仕事です。今日の決定が、システムが最初に構想されてから数年または数十年後に稼働するときにまだ有効であることを保証する手法はありません。ただし、システムエンジニアリングのプロセスをサポートする手法はあります。例として、ソフトシステム方法論、ジェイ・ライト・フォレスターのシステムダイナミクス法、統一モデリング言語（UML）などが挙げられ、すべて現在、エンジニアリングの意思決定プロセスをサポートするために調査、評価、開発されています。

教育

システム工学の教育は、通常の工学コースの延長として見られることが多く、[ 31 ]工学部の学生は伝統的な工学分野（航空宇宙工学、土木工学、電気工学、機械工学、製造工学、産業工学、化学工学など）のいずれかの基礎的な背景に加えて、システムエンジニアとして効果的な実践的な現実世界での経験が必要であるという産業界の姿勢を反映しています。システム工学を明確に専門とする大学の学部プログラムの数は増えていますが、まだ一般的ではなく、そのような内容を含む学位は、ほとんどの場合、産業工学のBSとして提示されます。通常、プログラム（単独または学際研究と組み合わせて）は、学術的および専門的トラックの両方で大学院レベルから提供され、MS / MEngまたはPh.D. / EngDの学位が授与されます。

INCOSEは、スティーブンス工科大学のシステム工学研究センターと共同で、適切な認定を受けた教育機関における世界中の学術プログラムのディレクトリを定期的に更新しています。[ 6 ] 2017年現在、このディレクトリには北米の140以上の大学が掲載されており、システム工学の学部および大学院プログラム400以上を提供しています。この分野が独立した専門分野として広く認知されるようになったのはごく最近のことで、同誌の2009年版では、そのような学校とプログラムの数はそれぞれわずか80と165と報告されています。

システム エンジニアリングの教育は、システム中心またはドメイン中心として捉えることができます。

  • システム中心のプログラムでは、システム エンジニアリングを独立した分野として扱い、ほとんどのコースではシステム エンジニアリングの原則と実践に重点を置いて教えられます。
  • ドメイン中心のプログラムでは、エンジニアリングの他の主要分野と組み合わせて実践できるオプションとしてシステム エンジニアリングが提供されます。

どちらのパターンも、コアエンジニアに求められる深い知識を持ち、学際的なプロジェクトを監督できるシステムエンジニアを育成することを目指しています。[ 32 ]

システムエンジニアリングのトピック

システムエンジニアリングツールとは、プロジェクトや製品におけるシステムエンジニアリングの実行を支援する戦略、手順、および技術です。これらのツールの目的は、データベース管理、グラフィカルブラウジング、シミュレーション、推論、ドキュメント作成、ニュートラルインポート/エクスポートなど多岐にわたります。[ 33 ]

システム

システム工学の分野では、 システムとは何かについて様々な定義があります。以下に、権威ある定義をいくつか示します。

  • ANSI / EIA -632-1999：「最終製品と特定の目的を達成するための製品の集合体。」[ 34 ]
  • DAUシステムエンジニアリングの基礎：「明示されたニーズや目的を満たす能力を提供する、人、製品、プロセスの統合された複合体。」[ 35 ]
  • IEEE Std 1220-1998：「関連性があり、その動作が顧客/運用ニーズを満たし、製品のライフサイクルの持続性を提供する要素とプロセスの集合または配置。」[ 36 ]
  • INCOSEシステムエンジニアリングハンドブック：「現実世界であらかじめ定義された動作を示し、個別にはその動作を示さない異種の部品と、コンポーネントおよび/またはサブシステムの統合された構成で構成される均質なエンティティ。」[ 37 ]
  • INCOSE：「システムとは、様々な要素を集合体として構築したもの、あるいはそれらが組み合わさって、個々の要素だけでは達成できない成果を生み出すものです。要素、あるいは部品には、人、ハードウェア、ソフトウェア、設備、ポリシー、文書など、システムレベルの成果を生み出すために必要なすべてのものが含まれます。成果には、システムレベルの品質、特性、特徴、機能、動作、パフォーマンスが含まれます。システム全体によって付加される価値は、個々の部品が単独で提供する価値を超えて、主に部品間の関係性、つまり部品がどのように相互接続されているかによって生み出されます。」[ 38 ]
  • ISO/IEC 15288:2008：「1つ以上の明示された目的を達成するために構成された相互作用する要素の組み合わせ。」[ 39 ]
  • NASAシステムエンジニアリングハンドブック：「(1) ニーズを満たす能力を生み出すために連携して機能する要素の組み合わせ。要素には、この目的のために必要なすべてのハードウェア、ソフトウェア、機器、施設、人員、プロセス、および手順が含まれる。(2) システムを構成する最終製品（運用機能を実行するもの）とイネーブリング製品（運用最終製品にライフサイクルサポートサービスを提供するもの）」[ 40 ]

システムエンジニアリングプロセス

システムエンジニアリングのプロセスは、製品を定義するために必要なすべての創造的、手作業的、技術的な活動を包含し、システム定義を製品の製造と展開に十分な詳細なシステム設計仕様に変換するために実行する必要がある。システムの設計と開発は、それぞれ異なる定義を持つ4つの段階に分けられる。[ 41 ]

  • タスク定義（情報定義）
  • 概念段階（基本的な定義）
  • 設計段階（形成的定義）
  • 実装段階（製造定義）

ツールは、その用途に応じて、システムエンジニアリングプロセスのさまざまな段階で使用されます。[ 23 ]

モデルの使用

モデルはシステム工学において重要かつ多様な役割を果たします。モデルは以下のようにいくつかの方法で定義できます。[ 42 ]

  • 現実世界に関する特定の質問に答えるために設計された現実の抽象化
  • 現実世界のプロセスまたは構造の模倣、類似物、または表現。
  • 意思決定者を支援するための概念的、数学的、または物理的なツール。

これらの定義は、システム設計の検証に用いられる物理工学モデルだけでなく、機能フローブロック図のような概略モデルや、トレードス​​タディプロセスに用いられる数学的（すなわち定量的）モデルも包含するほど広範です。本節では、トレードス​​タディプロセスに用いられる数学的（すなわち定量的）モデルに焦点を当てます。[ 42 ]

貿易研究において数学モデルや図表を用いる主な理由は、既知または推定可能な一連の量から、システムの有効性、性能または技術的特性、そしてコストを推定することです。通常、これらの結果変数全てを提供するには、複数の個別のモデルが必要です。あらゆる数学モデルの核心は、その入力と出力の間に存在する意味のある定量的関係の集合です。これらの関係は、構成量を合計して合計値を求めるような単純なものから、重力場における宇宙船の軌道を記述する一連の微分方程式のような複雑なものまで様々です。理想的には、これらの関係は相関関係だけでなく因果関係も表します。[ 42 ]さらに、システムエンジニアリング活動を成功させる鍵は、これらのモデルを効率的かつ効果的に管理し、システムをシミュレーションするために使用する方法でもあります。しかしながら、多様な分野では、システムエンジニアリングにおけるモデリングとシミュレーションに関する問題が繰り返し発生することが多く、「モデリングとシミュレーションに基づくシステムエンジニアリング」という名称の下、異なる科学コミュニティとエンジニアリングコミュニティの間で手法の相互交流を図る新たな進歩が見られます。[ 43 ]

モデリング形式とグラフィカル表現

システムエンジニアの主な目的が複雑な問題を理解することである場合、システムの機能要件とデータ要件を伝えるためにシステムのグラフィック表現が使用されます。[ 44 ]一般的なグラフィック表現には次のものがあります。

グラフィカルな表現は、システムの様々なサブシステムまたは部分を、機能、データ、またはインターフェースを介して関連付けます。上記の手法のいずれか、またはすべてが、業界の要件に基づいて使用されます。例えば、システム間のインターフェースが重要な場合には、N2チャートが使用されることがあります。設計フェーズでは、システムの 構造モデルと動作モデルを作成します。

要件が理解されたら、システム エンジニアの責任は、それらを洗練し、他のエンジニアとともに、仕事に最適なテクノロジを決定することです。この時点で、トレード スタディから始まり、システム エンジニアリングでは、重み付けされた選択を使用して最適なオプションを決定することを推奨しています。意思決定マトリックス、または Pugh 法は、重要なすべての基準を考慮しながらこの選択を行う 1 つの方法です (別の方法として QFD があります)。トレード スタディの結果は設計に反映され、設計は (要件を変更せずに) システムのグラフィック表現に再び影響を与えます。SE プロセスでは、この段階は、実行可能なソリューションが見つかるまで実行される反復的なステップを表します。意思決定マトリックスは、多くの場合、統計分析、信頼性分析、システム ダイナミクス (フィードバック制御)、最適化手法などの手法を使用して作成されます。

その他のツール

システムモデリング言語

システムモデリング言語（SysML）は、システムエンジニアリングアプリケーションに使用されるモデリング言語であり、広範囲の複雑なシステムの仕様、分析、設計、検証、妥当性確認をサポートします。[ 45 ]

ライフサイクルモデリング言語

ライフサイクルモデリング言語（LML）は、システムエンジニアリングのために設計されたオープンスタンダードのモデリング言語であり、概念、利用、サポート、廃止の各段階のライフサイクル全体をサポートします。[ 46 ]

多くの関連分野はシステム工学と密接に結びついていると考えられます。以下の分野は、システム工学を独自の存在として発展させるのに貢献してきました。

認知システム工学

認知システム工学（CSE）は、人間機械システムまたは社会技術システムの記述と分析に対する特定のアプローチである。[ 47 ] CSEの3つの主なテーマは、人間が複雑性にどのように対処するか、人工物の使用によって作業がどのように達成されるか、そして人間機械システムと社会技術システムがどのように共同認知システムとして記述できるかである。CSEは誕生以来、認知工学とも呼ばれる科学的分野として認められている。特に共同認知システム（JCS）の概念は、複雑な社会技術システムをさまざまな解像度で記述する方法を理解する方法として広く使用されるようになった。20年以上にわたるCSEの経験は、広範囲にわたって説明されてきた。[ 48 ] [ 49 ]

構成管理

システムエンジニアリングと同様に、防衛・航空宇宙産業で実践されている構成管理は、広範なシステムレベルの実践です。この分野はシステムエンジニアリングの業務内容と類似しており、システムエンジニアリングは要件の開発、開発項目への割り当て、検証を扱います。一方、構成管理は要件の捕捉、開発項目へのトレーサビリティ、そして開発項目の監査を扱い、システムエンジニアリングやテスト・検証エンジニアリングが客観的なテストを通じて達成し、実証した目的の機能と成果が開発項目で達成されていることを確認します。

制御工学

制御工学とその制御システムの設計・実装は、ほぼあらゆる産業で広く利用されており、システム工学の大きなサブフィールドです。自動車のクルーズコントロールや弾道ミサイルの誘導システムは、その好例です。制御システム理論は、解空間の探究や制御プロセスの解析のための新しい手法の開発を伴う、応用数学の活発な分野です。

産業工学

産業工学は、人、資金、知識、情報、設備、エネルギー、材料、プロセスからなる統合システムの開発、改善、実装、評価に関わる工学の一分野です。産業工学は、工学分析と設計の原理と手法に加え、数学、物理学、社会科学の知見も活用し、これらのシステムから得られる結果を規定、予測、評価します。

生産システムエンジニアリング

生産システム工学（PSE）は、生産システムの基本原理を明らかにし、それを分析、継続的な改善、設計に活用することを目的とした、エンジニアリングの新しい分野です。[ 50 ]

インターフェースデザイン

インターフェース設計とその仕様は、システムの構成要素が、必要に応じてシステムの他の部分や外部システムと接続し、相互運用できるようにすることに関係しています。インターフェース設計には、システムインターフェースが、機械的、電気的、論理的インターフェース（予約済み配線、プラグスペース、コマンドコード、通信プロトコルのビットなど）を含む新しい機能を受け入れることができるようにすることも含まれます。これは拡張性として知られています。ヒューマンコンピュータインタラクション（HCI）またはヒューマンマシンインターフェース（HMI）は、インターフェース設計のもう1つの側面であり、現代のシステムエンジニアリングの重要な側面です。システムエンジニアリングの原則は、ローカルエリアネットワークおよびワイドエリアネットワークの通信プロトコルの設計に適用されます。

メカトロニクス工学

メカトロニクス工学は、システム工学と同様に、動的なシステムモデリングを用いて具体的な構造を表現する学際的な工学分野です。この点ではシステム工学とほとんど区別がつきませんが、大きな一般化や関係性よりも、より細かい詳細に焦点を当てている点が異なります。そのため、両分野は、実践方法論ではなく、プロジェクトの範囲によって区別されます。

オペレーションズリサーチ

オペレーションズ・リサーチはシステム工学を支えるものです。簡単に言えば、オペレーションズ・リサーチは、複数の制約条件の下でのプロセスの最適化に取り組んでいます。[ 51 ] [ 52 ]

パフォーマンスエンジニアリング

パフォーマンス エンジニアリングは、システムがその寿命全体にわたって顧客の期待に応えるパフォーマンスを保証するための分野です。パフォーマンスは通常、特定の操作が実行される速度、または単位時間内にそのような操作の数を実行する能力として定義されます。実行待ちの操作がシステム容量の制限によって抑制されると、パフォーマンスが低下することがあります。たとえば、パケット交換ネットワークのパフォーマンスは、エンドツーエンドのパケット転送遅延、または 1 時間に交換されるパケット数によって特徴付けられます。高性能システムの設計では分析またはシミュレーション モデルが使用されますが、高性能実装の提供には徹底したパフォーマンス テストが含まれます。パフォーマンス エンジニアリングでは、そのツールとプロセスに 統計、待ち行列理論、および確率論に大きく依存しています。

プログラム管理とプロジェクト管理

プログラムマネジメント（またはプロジェクトマネジメント）はシステムエンジニアリングと多くの類似点がありますが、システムエンジニアリングの工学的起源よりも広範な起源を持っています。プロジェクトマネジメントは、プログラムマネジメントとシステムエンジニアリングの両方と密接に関連しています。どちらも、管理プロセスにおける学際的な懸念事項を評価するためのエンジニアリング支援ツールとしてスケジューリングを含んでいます。特に、リソース、パフォーマンス特性、リスクとタスクの所要期間との直接的な関係、あるいはタスク間の依存関係とシステムライフサイクル全体にわたる影響は、システムエンジニアリングの関心事です。

提案エンジニアリング

提案エンジニアリングとは、科学的および数学的原理を応用し、費用対効果の高い提案開発システムを設計、構築、運用することです。基本的に、提案エンジニアリングは「システムエンジニアリングプロセス」を用いて費用対効果の高い提案を作成し、提案の成功確率を高めます。

信頼性工学

信頼性工学は、システムがその寿命全体にわたって顧客の信頼性に対する期待を満たすこと（つまり、予想よりも頻繁に故障しないこと）を保証する分野です。故障の予測に加えて、故障の予防も同様に重要です。信頼性工学はシステムのあらゆる側面に適用されます。保守性、可用性（ディペンダビリティ、または一部の人々はRAMSと呼ぶ）、そして統合ロジスティクスサポートと密接に関連しています。信頼性工学は、故障モード影響解析（FMEA）やハザードフォールトツリー解析といった安全工学、そしてセキュリティ工学において常に重要な要素です。

リスク管理

リスク管理、すなわちリスクを評価し対処する実践は、システムエンジニアリングの学際的な側面の一つです。開発、調達、運用活動において、コスト、スケジュール、性能特性とのトレードオフにリスクを組み込むことは、システムライフサイクル全体にわたる、そしてシステムエンジニアリングの学際的な技術的アプローチを必要とする、トレーサビリティと評価の反復的な複雑な構成管理、スケジューリングと要件管理を伴います。システムエンジニアリングでは、リスク管理は、全体的な取り組みに統合されたリスク管理のための構造化されたプロセスを定義、調整、実装、監視します。[ 53 ]

安全工学

安全工学の技術は、専門分野に属さないエンジニアが複雑なシステムを設計する際に、安全性に重大な障害の発生確率を最小限に抑えるために活用することができます。「システム安全工学」機能は、新たな設計における「安全上のハザード」を特定し、システム設計では排除できない（潜在的に）危険な状態の影響を「軽減」する技術を支援する場合があります。

セキュリティエンジニアリング

セキュリティエンジニアリングは、制御システムの設計、信頼性、安全性、そしてシステムエンジニアリングの実践コミュニティを統合する学際的な分野と捉えることができます。システムユーザー、システムターゲット、そして人、オブジェクト、プロセスの 認証といった専門分野が含まれる場合もあります。

ソフトウェアエンジニアリング

ソフトウェアエンジニアリングは、その黎明期から、現代​​のシステムエンジニアリングの実践の形成に貢献してきました。大規模なソフトウェア集約型システムの複雑な処理に使用される技術は、システムエンジニアリングのツール、手法、そしてプロセスの発展と再構築に大きな影響を与えてきました。

参照

参考文献

  1. ^ Schlager, J. (1956年7月). 「システムエンジニアリング：現代開発の鍵」. IRE Transactions on Engineering Management . EM-3 (3): 64– 66. Bibcode : 1956IRTEM...3...64S . doi : 10.1109/IRET-EM.1956.5007383 . S2CID  51635376 .
  2. ^ホール、アーサー・D. (1962).システムエンジニアリングの方法論. ヴァン・ノストランド・ラインホールド. ISBN 978-0-442-03046-9。{{cite book}}:ISBN / 日付の非互換性（ヘルプ）
  3. ^アンブレロ、スティーブン（2021年4月5日）「自律型兵器の人間による意味のある制御を理解するための抽象化レベルの結合：2層アプローチ」倫理と情報技術. 23 (3): 455– 464. doi : 10.1007/s10676-021-09588-w . hdl : 2318/1784315 . ISSN 1572-8439 . 
  4. ^ Sage, Andrew Patrick (1992).システムエンジニアリング. Wiley IEEE. ISBN 978-0-471-53639-0。
  5. ^ INCOSE Resp Group (2004年6月11日). 「Genesis of INCOSE」 . 2006年9月25日時点のオリジナルよりアーカイブ。2006年7月11日閲覧。
  6. ^ a b INCOSE /学術評議会. 「Worldwide Directory of SE and IE Academic Programs」 . 2018年12月26日時点のオリジナルよりアーカイブ。2019年2月4日閲覧。
  7. ^複雑性の克服：防衛システム取得のための教訓、防衛エンジニアリンググループ、ユニバーシティ・カレッジ・ロンドン、2005年。
  8. ^システムエンジニアリングハンドブック、バージョン2a。INCOSE。2004年。
  9. ^ NASAシステムエンジニアリングハンドブック. NASA . 1995. SP-610S.
  10. ^ 「デレク・ヒッチンズ」 INCOSE UK 2007年6月2日閲覧。
  11. ^ Goode, Harry H.; Robert E. Machol (1957).システムエンジニアリング：大規模システムの設計入門. McGraw-Hill. p. 8. LCCN 56011714 . 
  12. ^チェスナット、ハロルド（1965年）『システムエンジニアリングツール』Wiley. ISBN 978-0-471-15448-8。
  13. ^ Rhodes, Donna; Hastings, Daniel (2004年3月). 「エンジニアリングシステム内の分野としてシステムエンジニアリングを進化させる必要性」MITエンジニアリングシステムシンポジウム. CiteSeerX 10.1.1.86.7496 . 
  14. ^ a bチェックランド、ピーター（1999年）。ピスター、著者（編）『システム思考とシステム実践』ジョン・ワイリー・アンド・サンズ。
  15. ^チェックランド、ピーター (1999). ピスター、オーサー (編).システム思考、システム実践. ジョン・ワイリー・アンド・サンズ.2012. システムエンジニアリング知識体系。1.0 版: スティーブンス研究所および海軍大学院。
  16. ^オリバー、デイビッド・W.、ティモシー・P・ケリハー、ジェームズ・G・キーガン・ジュニア (1997). 『モデルとオブジェクトによる複雑システムのエンジニアリング』 マグロウヒル. pp.  85–94 . ISBN 978-0-07-048188-6。
  17. ^ 「The SE VEE」 SEOR、ジョージ・メイソン大学。2007年10月18日時点のオリジナルよりアーカイブ。2007年5月26日閲覧。
  18. ^ Ramo, Simon ; Robin K. St.Clair (1998).システムアプローチ：科学と実践的常識の融合による複雑な問題への新たな解決策(PDF) . カリフォルニア州アナハイム：KNI. 2012年8月6日時点のオリジナル(PDF)からアーカイブ。 2007年8月18日閲覧。
  19. ^ 「4. システムエンジニアリング」（PDF） .国防調達ガイドブック.国防調達大学. 2015年8月12日閲覧。
  20. ^ 「コーネル大学のシステム工学プログラム」コーネル大学。 2007年5月25日閲覧。
  21. ^ 「ESDの教員と教育スタッフ」 MIT工学システム部門。 2007年5月25日閲覧。
  22. ^ 「コアコース、システム分析 - アーキテクチャ、動作、最適化」コーネル大学。 2007年5月25日閲覧。
  23. ^ a b「システムエンジニアリングの基礎」(PDF)。国防調達大学出版局。2001年。 2017年1月31日時点のオリジナル(PDF)からのアーカイブ。
  24. ^ Adcock, Rick. 「システムエンジニアリングの原則と実践」(PDF) . INCOSE, 英国. 2007年6月15日時点のオリジナル(PDF)からアーカイブ。 2007年6月7日閲覧。
  25. ^ 「システムエンジニアリング、キャリア機会、給与情報」ジョージ・メイソン大学、1994年。2007年9月22日時点のオリジナルよりアーカイブ。 2007年6月7日閲覧。
  26. ^ a b「システムエンジニアリングの価値を理解する」(PDF) 。 2007年6月15日時点のオリジナル(PDF)からアーカイブ。 2007年6月7日閲覧。
  27. ^ Elm, Joseph P. 「Surveying Systems Engineering Effectiveness」（PDF） . ペンシルベニア州ピッツバーグ：カーネギーメロン大学. 2007年6月15日時点のオリジナル（PDF）からアーカイブ。 2023年3月16日閲覧。
  28. ^ 「コンセンサスによるシステムエンジニアリングコスト見積もり」 。 2007年6月7日閲覧。
  29. ^ Sage, Andrew P. ; Olson, Stephen R. (2001). 「システムエンジニアリングにおけるモデリングとシミュレーション」 .シミュレーション. 76 (2): 90. doi : 10.1177/003754970107600207 . S2CID 3016918. 2007年10月21日時点のオリジナルよりアーカイブ。 2007年6月2日閲覧。 
  30. ^ Smith, EC Jr. (1962年9月). 「システムエンジニアリングにおけるシミュレーション」(PDF) . IBM Systems Journal . 1. IBM Research: 33–50 . doi : 10.1147/sj.11.0033 . 2007年6月4日時点のオリジナル(PDF)からアーカイブ。 2023年3月16日閲覧。
  31. ^ 「システムエンジニアリング教育に関する教授法の推奨事項」（PDF）2007年6月7日閲覧。
  32. ^ 「システムエンジニアリング認定の展望」（PDF）INCOSE。2007年6月15日時点のオリジナル（PDF）からアーカイブ。 2007年6月7日閲覧。
  33. ^ Steven Jenkins. 「システムエンジニアリングツールの未来」（PDF） . NASA. p. 15. 2007年9月26日時点のオリジナル（PDF）からアーカイブ。 2007年6月10日閲覧。
  34. ^ 「システムのエンジニアリングプロセス」電子工業連盟（EIA ）1999年。 2010年7月5日時点のオリジナルよりアーカイブ。 2018年6月17日閲覧。
  35. ^ 「システムエンジニアリングの基礎」(PDF) OCW.MIT.edu 2001年1月.
  36. ^ 「システムエンジニアリングプロセスの適用と管理に関する標準」 IEEE。 2009年8月1日時点のオリジナルよりアーカイブ。
  37. ^ 「システムエンジニアリングハンドブック」 INCOSE 、 2007年。 2015年3月18日時点のオリジナルよりアーカイブ。2009年7月10日閲覧。
  38. ^ 「INCOSEフェローのコンセンサス」 INCOSE 、 2006年。 2006年10月29日時点のオリジナルよりアーカイブ。2009年7月10日閲覧。
  39. ^ 「システムとソフトウェアエンジニアリング - システムライフサイクルプロセス」 2008年。 2019年8月6日時点のオリジナルよりアーカイブ。2009年7月10日閲覧。
  40. ^ NASAシステムエンジニアリングハンドブック（PDF） . NASA . 2007. NASA/SP-2007-6105.
  41. ^ J. Lienig; H. Bruemmer (2017).電子システム設計の基礎. Springer International Publishing. pp.  6– 7. doi : 10.1007/978-3-319-55840-0 . ISBN 978-3-319-55839-4。
  42. ^ a b c「システム分析とモデリングの問題 - NASAシステムエンジニアリングハンドブック」(PDF) 1995年、p. 85。2008年12月17日時点のオリジナル(PDF)からのアーカイブ。
  43. ^ジャンニ・ダニエレ、ダンブロージョ・アンドレア、トールク・アンドレアス編（2014年12月4日）。モデリングとシミュレーションに基づくシステムエンジニアリングハンドブック（第1版）。CRC Press。ISBN 9781466571457。
  44. ^ Long, Jim (2002). 「システムエンジニアリングにおける一般的なグラフィカル表現間の関係」(PDF) . VitechCorp . 2017年8月13日時点のオリジナル(PDF)からのアーカイブ。
  45. ^ 「OMG SysML仕様」(PDF) . SysMLオープンソース仕様プロジェクト. p. 23 . 2007年7月3日閲覧。
  46. ^ 「LML仕様」(PDF) . LML運営委員会. p. 4. 2014年5月6日時点のオリジナル(PDF)からアーカイブ。 2014年6月5日閲覧。
  47. ^ Hollnagel; Woods (1983). 「認知システム工学：新しいボトルに入った新しいワイン」 . International Journal of Man-Machine Studies . 18 (6): 583– 600. doi : 10.1016/S0020-7373(83)80034-0 . S2CID 15398274. 2023年11月16日閲覧。 
  48. ^ Hollnagel; Woods (2005). Joint cognitive systems: The foundations of cognitive systems engineering . Taylor & Francis. doi : 10.1201/9781420038194 . ISBN 9780429122224. 2023年11月16日閲覧。
  49. ^ Hollnagel; Woods (2006). Joint cognitive systems: Patterns in cognitive systems engineering . Taylor & Francis. doi : 10.1201/9781420005684 . ISBN 9780429127663. 2023年11月16日閲覧。
  50. ^ Li, Jingshan; Meerkov, Semyon M. (2009).生産システム工学. doi : 10.1007/978-0-387-75579-3 . ISBN 978-0-387-75578-6。
  51. ^ポストレル、バージニア州 (2004年6月27日). 「Operation Everything」 .ボストン・グローブ. 2012年3月31日時点のオリジナルよりアーカイブ。 2005年11月30日閲覧。
  52. ^ Crissey, Mary (2004). "SHHHH... It's a Secret" . sas.com Magazine . 2005年9月20日時点のオリジナルよりアーカイブ。 2005年11月30日閲覧。
  53. ^ 「リスク管理ツールキット」。MITRE、SEプロセスオフィス。 2016年9月8日閲覧。

さらに読む

「 https://en.wikipedia.org/w/index.php?title=Systems_engineering&oldid=1333158907」より取得