本研究室は、複雑なシステムを対象とした研究と、研究成果に基づいた教育活動を行っています。

これらの教育や研究活動の基礎となる、システム思考やモデルベースのアプローチ、システムズエンジニアリング、システムズアプローチなど、Systemsを扱う方法論やツール(Systems methods)、デジタルツインや1Dシミュレーションなどについて説明します。

Our laboratory conducts research on complex systems and educational activities based on research results.

Methodologies and tools for dealing with Systems, such as systems thinking, model-based approaches, systems engineering, and systems approaches (Systems methods), digital twin and 1D simulation, which are the basis of these educational and research activities, will be explained.

はじめに

　社会や産業界は人工知能や情報通信技術に大きな期待をかけています。しかし、人間の行動を変えずに、人間の役割の一部を高度な技術にそのまま代替させるという方針は困難を伴うことがあります。

　この難しさを解決するための、人間と技術の組み合わせとしての全体システムのデザインに役立つ考え方をまとめています。

システム思考

　システム思考とは、対象をシステムとして考えることです。システムとは、複数の要素からなり、要素を組み合わせた際に個々の要素とは異なる機能や、個々の要素の和よりも大きな機能を発現するものと定義されます。

　社会やビジネスの現場では、複数の企業の製品やサービスを組み合わせることでより大きな機能や、他では実現の難しい機能を実現します。一方で、組み合わせによるシステム化がうまく働かない場合の対処はより困難なものになります。

本研究室で課題解決型の研究テーマに取り組む際には、対象となる問題を取り巻く環境をシステムとして記述した後、解決への道筋の検討を行って研究プロジェクトをデザインします。

Introduction

Society and industry have high expectations for AI and IT. However, the policy of substituting a part of human role with technology without changing human behavior and habit can be difficult.

To solve this difficulty, we have summarized the ideas that are useful for designing the entire system as a combination of humans and technology. 

Systems Thinking

Systems Thinking is a process by which we define phenomena in the world as systems. A system consists of multiple elements that, when combined, create a complexity of behavior the is not otherwise apparent merely from the individual elements. Recall the old adage, "the whole is greater than the sum of its parts." Similarly, the function that defines a system is often more complex than the mere collection of its individual elements.

In the society and business practice, by combining the products and services of multiple companies, we can realize larger or different beneficial functions. On the other hand, it becomes more difficult to deal with when systematization by combination does not work well.

When working on a problem-based theme in our laboratory, we design a related research project by describing the environment surrounding the target problem as a system. Once we define the relevant system, we then explore one or more paths to a solution.

システムとは

システムとは、個々の要素よりも大きい、あるいは異なる機能を提供するものです。ただし、ここでは人工的なシステムを想定しています。例えば、物流や公共交通などは、様々な機能を高い水準で人間に提供する複雑なシステムですが、技術や運用の複雑さから新たな問題が引き起こされます。このページでは、システム思考が、これらの問題を解決するためにどのように有効かという観点で説明します。

創発とシステム

　システムの一つの例として車を取り上げ、車はボディとエンジンとタイヤの3つの要素からなるものと考えます。ボディは人や荷物を保持し、エンジンは燃料を回転のエネルギーに変換し、タイヤは軸の回転エネルギーをボディの駆動力に変換します。この3つの要素を組み合わせると、個々の要素では発現されなかった人や荷物の移動という機能が得られます。このような場合に車はシステムとして考えられます。

また、新しい機能やより大きな機能が発現する現象を「創発」と呼びます。各要素の組み合わせにより機能の性能が思ったように伸びない、不都合な現象が発生する場合にも望ましくない創発と考えます。例えば、渋滞などのように道路と車両という各要素が適切に機能していても発生する性能低下などが対応します。創発に注目するなら、創発を伴う要素の集合体がシステムであると定義することもできます。

不確実性

　多くの場合、システムは不確実性を含む問題を解決したり、あるいはシステム自身が不確実性を内包していたりします。

　不確実性には、偶然によるもの(Aleatory)と、知識の不確かさによるもの(Epistemic)の二つの種類があります。偶然によるもの(Aleatory)の例として、例えば赤と白のボールが半分ずつ入っている箱からランダムに一つのボールを取り出すときにそのボールの色を予測することはできません。この問題は、赤と白のボールの割合がわからないとき、知識の不確かさによる(Epistemic)問題に変わります。

このほかには、そもそも取り出されるボールの色の種類が予測できないという不確実性もありますが、ここでは対象にしません。

　システム思考のフレームワークは社会や産業界をシステムとして考えることで、その不確実性と複雑さに対処するためのものです。

What is system?

We expect engineered system here, not general definition of system. We try to explain how systems thinking can support problem solving activities of complex systems.

We define an engineered system as a combination of components that work in synergy to collectively perform a useful function. The engineered system could, for example, wholly or in part constitute a new technology for a new product line a new manufacturing process, a technology to improve the delivery of a service, or an infrastructure system [ERC/NSF webpage]. 

Emergence and Systems

Driving a car as one example of a system. We can think of a car as consisting of three elements: body, engine, and tires. The body holds people and cargo, the engine converts fuel into energy for rotation, and the tires convert the rotational energy of the axle into driving force for the body. When these three elements are combined, they provide a function of moving people and cargo that could not be expressed by the individual elements. In such a case, a car can be considered as a system.

The phenomenon of the new or larger functions being created from simple elements is called "emergence." When the performance of a function does not grow as expected due to the combination of each element, or when an undesirable phenomenon occurs, it is also considered as "undesirable emergence." For example, traffic congestion is a type of undesirable emergence that causes a decrease in performance even when each element (road and vehicle) is functioning properly. If we focus on emergence, we can also define a system as a collection of elements with emergence.

Uncertainty

In many cases, the system solves a problem that involves uncertainty, or the system itself contains uncertainty.

There are two types of uncertainty:  Aleatory and Epistemic. As an example of Aleatory, it is not possible to predict the color of a ball when it is randomly picked out of a box containing half of each of the red and white balls. This problem turns into an Epistemic problem when you don't know the proportion of red and white balls.

There is also the uncertainty that the type of color of the ball that is taken out is unpredictable in the first place, but we will not cover it here.

The framework of systems thinking is to deal with the uncertainty and complexity of society and industry as a system. 

システムズアプローチ 

　社会や産業自体が理解の難しい複雑なシステムとなっているために、社会や産業の問題は想定している創発的機能が何らかの原因で動かなくなっている現象や、想定外の望ましくない創発が発生している現象であると考えています。このため、システムとしての社会や産業における創発を適切にマネジメントすることにより問題定義から課題解決までを行うアプローチを考えます。このように、課題解決を行うにあたり、対象をシステムとして考えるシステム思考および関連手法を用いてアプローチのことをシステムズアプローチと呼んでいます。

　本研究室では、利害関係に基づいたシステムへの要求の記述、サブシステム間の関係性に注目した機能、振る舞いを記述する方法を組み合わせて問題定義から解決に取り組むアプローチをシステムズアプローチとして教育プログラムに組み込んでいます。【参考資料】

システムデザインプロセス

　ここではNASA Systems Engineering Handbook (SP-2016-6105)のFIGURE 4.0-1を前提に説明します。システムの設計プロセスを、Stakeholder Expectations, Requirement Definition, Logical Decomposition, Design Solution Definitionの4つの反復と想定します。

　Stakeholder Expectationsでは、Stakeholder Value Networkなどの形式で記述する、Structured Interviewの結果をまとめる、など、ある程度属人的な要素を含んだ方法により利害関係者の関係性を定義していくことなります。また、利害関係者やユーザーがどのようなことを期待しているか、要求しているかを記述します。ユーザーの立場では、ConOps(Concept of Operation)としてまとめることが有益です。

　Requirement Definitionでは、前述の利害関係者の期待を、システムが満たすべき技術的・定量的な要求へと変換します。システムの要件という言葉が該当します。期待から要件への変換作業には、機能要求や非機能要求の概念、狩野モデルなどによる品質要素の分析、などが利用できます。

　Logical Decompositionでは、定義した要件を満たしていくためのシステムはシステムアーキテクチャなどの形で具体化されます。ここでは、OPMやSysMLなどのシステム記述言語が利用できます。

　Design Solution Definitionでは、具体化されたシステムアーキテクチャが、ConOpsを満たすことができるか、利害関係者の期待を満たすことができるか、などを検証します。このプロセスではシミュレーションなどの定量的なアプローチも必要になります。必要に応じてStakeholder Expectationsからやり直すこともあります。これらの4つのプロセスを反復しながら、システムの設計は洗練され、確定します。

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

　理工学的な原則やコンセプト、手法を用いて、技術的なシステムの実現、利用、退役までを成功させる複数の専門分野にまたがるアプローチを、INCOSEではシステムズエンジニアリングと定義しています。航空宇宙産業や大規模情報システム開発など、創発的機能を組み合わせることがプロジェクトや製品の成功に必須の分野において、システムズエンジニアリングは標準技術として産業応用が進んでいます。

　日本における産業利用ではINCOSEの日本支部のJCOSEがあります。

　前述のNASAのSystems Engineering Handbookの1995年、2007年、2016年の版を比べてみると、技術的な複雑さに注目していた1995年のシステムズエンジニアリングは、2007年には利害関係者を明示的に対象に含めました。1995年のシステムズエンジニアリングの技術寄りの側面は、SysMLやMBSEのベストプラクティスとして一部の産業で実用化されていると考えられます。一方で、運用に複数の利害関係者が関わる大規模複雑システムを対象とした2007年以降の利害関係や要求に重きを置いたシステムズエンジニアリングは、情報通信技術で接続性が増している現在のシステムでは重要度が増していますが、産業界への実装は難しく進んでいないと考えています。

システムアーキテクチャ

　Crawleyらは、システムを物理的あるいは情報的に具体化したものを「フォーム」と呼んでいます。また、フォームに対して、システムが行うことは「機能」と呼ばれます。具体例として輸送システムを挙げると、トラックなどの輸送機器が「フォーム」で、貨物の位置を変更するというアクションが「機能」となります。さらに、フォームと機能の関連付けを「コンセプト」と呼んでいます。

　先ほどの例で手押し車などで輸送することを考えると、異なる「コンセプト」を提案したことになります。「コンセプト」を定めるとシステムの性能特性が決まるため、「コンセプト」の決定は慎重に行われるべきです。なお、トラックは数トンの荷物を数キロメートル以上運ぶのに適した性能を出すけれど、段ボール箱をビルの中で輸送するなら手押し車の方が適しているというような違いについて、ここでは性能特性と呼んでいます。「コンセプト」はシステムのビジョンを表していますが、まだ具現化されていないメンタルなイメージです。

　「システムアーキテクチャ」とは、コンセプトを具現化したものとなります。例えば、トラックによる輸送システムという「コンセプト」を選定しても、トラックが2トンか10トンでは技術システムとして大きく異なり、まだ大きな自由度を持った状態です。「システムアーキテクチャ」を決定するとは、トラックの航続距離や最大積載量、安全を確保するための装置などを定め、すべての「機能」に対して「フォーム」を割り当てていく作業です。

　異分野の専門家のコミュニケーションを深く効率的に行い、困難な問題について質の高い意思決定を行うためには、「フォーム」「機能」「コンセプト」「システムアーキテクチャ」といった概念をコミュニケーションの基盤として利用することが有益と考えています。

モデルベースシステムズエンジニアリング(MBSE)

モデルベースシステムズエンジニアリング(MBSE)は、複雑なシステムの中で利用される製品の開発を成功させるための重要な技術です。この中でモデルとは、製品に関係する概念や関係性、現象、構造やシステムを記述したものであり、記述されたモデルは理解や推論、デザインにおける意思決定を支援します。モデルを用いた製品開発プロセスをシステムズエンジニアリングに関連付けたものがMBSEです。MBSEでは、システムの要求分析、アーキテクティング、振る舞いやパフォーマンスの分析、シミュレーションなどが行われ、ライフサイクルを通じた検討が行われます。

MBSEは複雑な製品を開発にするにあたって有益な概念ではあるが、Cameronらの報告でその難しさも指摘されている。

Systems Approach

As society and industry itself are complex systems that are difficult to understand, we believe that the problems in society and industry are phenomena in which the desired emergent functions are not working for some reason or in which unexpected and undesirable emergence is occurring. For this reason, we consider an approach that covers from problem definition to problem solving by appropriately managing emergence in society and industry as a system. This approach, which uses systems thinking and related methods to think of the target as a system, is called a systems approach.

In our laboratory, we incorporate the systems approach, which is an approach to solving problems from problem definition, into our educational programs by combining methods for describing system requirements based on interests, and describing functions and behaviors by focusing on the relationships among subsystems. (Reference material)

System Design Process

This section assumes FIGURE 4.0-1 of the NASA Systems Engineering Handbook (SP-2016-6105). We assume that the system design process consists of four iterations: Stakeholder Expectations, Requirement Definition, Logical Decomposition, and Design Solution Definition.

In Stakeholder Expectations, the relationships among stakeholders are defined using a method that includes some human elements, such as describing them in the form of a Stakeholder Value Network or summarizing the results of Structured Interview. In addition, the stakeholders and users will be able to define their own relationships. We will also describe what stakeholders and users expect and require. From the user's perspective, it is useful to summarize it as ConOps (Concept of Operation).

In Requirement Definition, aforementioned stakeholders' expectations are translated into technical and quantitative requirements that the system must meet. The term "system requirements" is applicable. To transform expectations into requirements, the concepts of functional and non-functional requirements, analysis of quality factors using the Kano model, etc., can be used.

In Logical Decomposition, the system for satisfying the defined requirements is materialized in the form of a system architecture. Here, system description languages such as OPM and SysML can be used.

In Design Solution Definition, we verify whether the embodied system architecture can satisfy ConOps, meet the expectations of stakeholders, and so on. This process also requires a quantitative approach such as simulation. If necessary, we may start over with Stakeholder Expectations. Through iterations of these four processes, the system design is refined and finalized.

Systems Engineering

INCOSE defines Systems Engineering as a multi-disciplinary approach that uses science and engineering principles, concepts, and methods to successfully implement, utilize, and retire technical systems. Systems engineering is increasingly being applied as a standard technology in industrial applications such as the aerospace industry and large-scale information systems development, where the combination of emergent capabilities is essential to the success of a project or product.

Industrial applications in Japan include JCOSE, the Japanese branch of INCOSE.

Comparing the 1995, 2007, and 2016 editions of NASA's Systems Engineering Handbook, the 1995 edition of Systems Engineering, which focused on technical complexity, explicitly included stakeholders in 2007; the 1995 The more technical-leaning aspects of systems engineering are considered practical in some industries as best practices in SysML and MBSE. On the other hand, we believe that the post-2007 interest- and requirements-oriented systems engineering for large complex systems involving multiple stakeholders in operation is becoming increasingly important in today's systems, which are increasingly connected by information and communication technology, but its implementation in industry has been difficult and slow. 

System Architecture

Crawley et al. refer to the physical or informational embodiment of a system as a "form. What the system does with respect to the form is called the "function". To take a transportation system as a concrete example, transportation equipment such as trucks is the "form" and the action of changing the position of cargo is the "function". Furthermore, the association between form and function is called "concept".

In the previous example, if we consider transportation by wheelbarrow, we have proposed a different "concept". Determining the concept should be done carefully because it determines the performance characteristics of the system. The difference between a 2 ton vehicle or 10 ton vehicle makes truck that performs well for transporting several tons of cargo over several kilometers and a wheelbarrow that is better suited for transporting cardboard boxes inside a building is referred to here as performance characteristics. The concept represents the vision of the system, but it is a mental image that has not yet been materialized.

The system architecture is the embodiment of the concept. For example, even if we select the "concept" of a truck-based transportation system, the technical system differs greatly if the truck is 2 tons or 10 tons, and it still has a large degree of freedom. Determining the "system architecture" is a process of assigning "forms" to all the "functions" of a truck, such as its cruising range, maximum load capacity, and devices to ensure safety.

We believe that it is beneficial to use concepts such as "form," "function," "concept," and "system architecture" as a basis for communication in order to enable deep and efficient communication among experts from different fields and to make high-quality decisions on difficult problems.

Model Based Systems Engineering (MBSE)

Model-based Systems Engineering (MBSE) is a key technology for successful development of products used in complex systems. Among them, "Model" describes concepts, relationships, phenomena, structures and systems related to a product, and the described model supports understanding, reasoning, and decision making in design. MBSE associates "Model" with systems engineering. MBSE includes system requirements analysis, architecting, behavior and performance analysis, simulation, etc., and designs the life cycle of the target system.

While MBSE is a useful concept for developing complex products, the difficulty is also pointed out by Cameron et al.

社会システムのデザインプロセス

社会システムのデザインではステークホルダーの要求の曖昧さを排除し、システムが達成する目標について利害関係者が共通認識を持つことがより重要となる。　

Design Process for Social Systems

In the design of social systems, it is more important to eliminate ambiguity in stakeholder demands and to ensure that stakeholders have a common understanding of the goals that the system will achieve.

定性的なモデリング

　対象をシステムとして考えることは、システムの機能や性能が発現するメカニズムを記述し、理解することです。システムの要素間の関係性を記述する、あるいはシミュレートするための手法を紹介します。

利害関係と要求の分析 

　対象が技術システムではなく社会や企業である場合、システムの要素として利害関係者が挙げられます。単純な販売店と顧客の関係では製品を受け取り、対価を払うという関係があります。長期間にわたって継続的に利用する製品の場合はサポート企業もいるかもしれず、車のような製品であれば燃料を提供する企業も必要です。このような場合、製品の単体性能が優れているだけでは顧客が望むものになりません。利害関係者である、販売店、メーカー、サポート企業、燃料提供企業などから創発する性能に顧客は魅力を感じ、購入することになります。利害関係者がどのような関係性で結ばれているか、あるいは利害関係により構成されているシステムがどういうものであるか、についてはStakeholder Value Networkという図式による記述が利用できます。特定の利害関係者への働きかけが他の利害関係者に想定外の影響を及ぼすこともあり得るので、そのようなことを図から読み取ることを考えます。

　利害関係を図示した後、顧客の要求の分析を行います。要求は、製品を所有するという基本的なものから、サポートや燃料補給の容易性などの補助的なものの2種類に分けて考えることができます。前者を機能要求、後者を非機能要求と呼んでいます。すべての利害関係者がどのような機能要求、非機能要求を持っているかを記述しながら理解を進めることで、顧客が望んでいる創発すべき機能を明らかにし、またその創発のためのメカニズムを組み立てることができます。

システム記述言語 OPMとSysML

一般的にはSysMLが利用されていると思われますが、講義ではOPMをシステム記述言語として採用しています。SysMLは、実務で必要な粒度の詳細図面まで複数のダイアグラムを組み合わせて記述できる強みがありますが、抽象度の高い検討を行うには細かすぎると考えています。OPMは単一のダイアグラムでシステムの基本動作に注力した記述ができるので、詳細な粒度の記述は難しいですが、システム全体を見通して 「フォーム」「機能」「コンセプト」「システムアーキテクチャ」といった概念を分析、検討することに向いています。

　少し具体的な例を述べると、人との連係が前提となっている複雑なプロダクト（ETCゲート、自動改札機、車両の制動支援、など…）の作動プロセスなどを詳細に分析するにはSysMLの適切なダイアグラムを活用する必要があり、プロセス全体（高速道路、鉄道運行、運転、など…）の見直しにはOPMによるモデリングが優れていると考えています。この２つの分類をもう少し明確にすると、複雑であっても単一のステークホルダーが開発するプロダクトにはSysMLを用い、ステークホルダーを超えて意思決定を行わなければならないシステムオブシステムズとしての属性を備えたシステム全体はOPMを用いるのがよいとなります。一例として、システムアーキテクチャーのフォームの概念は、OPMでは機能を実現するインストルメントあるいはエージェントとして記述することになります。エージェントは人間や人間のチームなどの知的な能力を持つ機能の実装手段であり、インストルメントは物理的な道具などの意思決定等を行わない手段である。

システムダイナミクス

対象のシステムについて要素間の因果関係とフィードバックに注目したシミュレーションモデル構築手法です。シミュレーションを伴わないフィードバック関係の理解に重きを置いた因果ループ図による定性モデルおよび要素間の関係性を連立微分方程式でモデル化した定量モデルを含みます。対象となるシステムの挙動を定性モデルを作成することにより理解する思考法をシステム思考と呼ぶこともありますが、ここでは対象をシステムとして考える他の手法も含めてシステム思考と呼びます。

Descriptive Modeling

To think of an object as a system is to describe and understand the mechanisms by which the system's functions and performance are manifested. This course introduces methods for describing or simulating the relationships among the elements of a system.

Stakeholder and Requirement Analysis

When the target is not a technical system but a society or a company, stakeholders are the elements of the system. In a simple dealer-customer relationship, there is a relationship of receiving a product and paying for it. For a product that is used continuously over a long period of time, there may be a support company, and for a product like a car, there needs to be a company that provides fuel. In such cases, just having a good standalone performance of the product is not enough to make it what the customer wants. Customers will be attracted to the performance created by the stakeholders, such as dealers, manufacturers, support companies, and fuel providers, and will buy the product. The relationship between the stakeholders can be described by using a diagram called Stakeholder Value Network.

After illustrating the relationships, analyze the customer's requirements. The requirements can be divided into two types: basic requirements such as ownership of the product and auxiliary requirements such as support and ease of refueling. We refer to the former as functional requirements and the latter as non-functional requirements. By describing what functional and non-functional requirements all stakeholders have, it is possible to identify the functions that customers want to be created and to build a mechanism for their creation.

OPM and SysML

Although Systems Modeling Language (SysML) is generally used, we use Object Process Methodology (OPM) as the system description language in this program. SysML has the advantage of being able to combine multiple diagrams to describe detailed drawings at the level of granularity required for practical use, but we believe that it is too detailed for highly abstract studies. Since OPM can focus on the basic behavior of the system in a single diagram, it is difficult to describe detailed granularity, but it is suitable for analyzing and examining concepts such as "form", "function", "concept", and "system architecture" from the perspective of the entire system.

To give a concrete example, in order to analyze in detail the operation process of a complex product (ETC gate, automatic ticket gate, vehicle braking support, etc.) that requires human interaction, it is necessary to use the appropriate diagram of SysML. For reviewing the whole process (highway, railroad operation, driving, etc...), I believe that OPM modeling is superior. To make the two categories a little clearer, SysML should be used for products that are complex but developed by a single stakeholder, while OPM should be used for entire systems with system-of-systems attributes where decisions must be made across stakeholders.

System Dynamics

This is a simulation model building method that focuses on the causal relationships and feedback between elements of the target system. It includes a qualitative model based on a causal loop diagram, which focuses on understanding the feedback relationship without simulation, and a quantitative model in which the relationship between elements is modeled by simultaneous differential equations. The method of understanding the behavior of a target system by creating a qualitative model is sometimes called systems thinking, but in this paper, other methods of thinking about the target as a system are also called systems thinking.

解析のためのモデリング

デジタルツイン

複雑なシステムでは、システムの構成要素を組み合わせて新しい機能を創発させます。例えば、エンジンとプロペラを組み合わせると、エンジンの回転により流体に力を加えるという機能が実現されます。ユーザーがエンジンとプロペラを組み合わせた技術システムを設計する際には、エンジンとプロペラは回転速度などの稼働条件に対してトルクや馬力、燃費や効率などが変化するという特性を考慮しながら、最大のパフォーマンスを発揮する組み合わせを探します。

これまでの技術システムの開発では、システムの利用条件を与えて最適なシステムの設計を行うことを指向してきました。船舶ならば積載量と船速、風や波などの条件を与え、ポンプならば流量や対象の流体の特性を与え、エンジンとプロペラの組み合わせを設計してきました。一方で、本来変化し続けているシステムの外的環境にシステムの運用を合わせていくことで、より効率を高めたいというニーズがあります。クラウドコンピューティングやセンシングの技術が進むにつれて、外部環境が変化する中での技術システムの運用のデータが精緻に得られるようになり、運用条件にシステムの設定を合わせていくようなスマートな制御も可能になりつつあります。シミュレーションによる様々な運用条件の事前検討、IoTによるセンシングによる運用状況の把握、センシングデータに基づいたシミュレーションにより技術システムの運用中の詳細も知ることのできるデジタルツイン技術がオペレーションの質を高めるコア技術になるとと考えられます。

1Dシミュレーション

自動車などの特定の製品や産業ドメインなどを対象とした場合のシミュレーションでは、配管系統と三次元配置設計など相互に影響するマルチドメインや、材料のミクロ構造から構造材の特性を評価するマルチスケール・マルチフィジックスなど、高度な練成解析も取り入れられつつあります。エンジンとプロペラであれば、単体の性能で評価するよりも、2つをシステム化した推進機構としての性能を評価する方が実務上望ましい結果が得られます。これは、単体で優れたエンジンであっても、組み合わせるプロペラによっては選択肢として最適ではなくなる可能性があるためです。エンジンとプロペラより複雑な、多くの要素を組み合わせた技術システムをデザインするにあたり、シミュレーションによるシステムの機能が発現されるまでの振る舞いの予測は非常に有益です。

　このようなデザインにおける意思決定をサポートするシミュレーション技術として、1Dシミュレーションという概念があります。1Dシミュレーションには明確かつ共通した定義はないようですが、多くの学術論文において常微分方程式の境界値問題が1Dモデルと呼ばれており、1Dシミュレーションはこの1Dモデルを基礎にしていると考えられます(see the reference)。このため、1Dシミュレーションは、多次元で表現される複雑なシステムの、機能などシステムの振る舞いを対象としたデザインプロセスにおいて、時間軸に注目した常微分方程式(1D)のようなモデル化によるシミュレーションと定義することがエンジニアリング分野では適切と考えます。

　一般的に1Dシミュレーションは設計したい機能に関する性能特性やその相互作用をモデル化します。プロペラとエンジンのみに注目した場合は、シャフトを通じて伝達される力を中心にモデル化し、エンジンやプロペラが船舶やポンプに収まるかなどの詳細は別途検討します。1Dシミュレーションにより機能設計を行う商用ソフトウエアは多く提供されており、CADやFEMなどとの統合によりCAEができるようなデザインプロセスも存在します。

　1Dシミュレーションという考え方は、複雑化の進んだ工業製品のデザインやサービスに関する意思決定の中でシミュレーション技術の活用を加速するものと考えられます。

Analytical Modeling

Digital Twin

In complex systems, the components of the system are combined to create new functions. For example, the combination of an engine and a propeller provides the function of applying force to a fluid through the rotation of the engine. When users design a technical system that combines an engine and a propeller, they look for the combination that provides the greatest performance, taking into account the characteristics of the engine and propeller, which vary in torque, horsepower, fuel consumption, and efficiency in relation to operating conditions such as rotational speed.

In the development of technical systems to date, we have been oriented toward designing the optimal system given the conditions under which the system will be used. For ships, we have designed engine and propeller combinations given the conditions of payload and ship speed, wind and waves, etc. For pumps, we have designed engine and propeller combinations given the flow rate and characteristics of the fluid under consideration. On the other hand, there is a need to increase efficiency by adapting system operations to the external environment of the system, which is inherently ever-changing. As cloud computing and sensing technologies advance, data on the operation of technical systems in a changing external environment can be obtained with greater precision, and smart control is becoming possible, such as matching system settings to operational conditions. Digital twin technology will become a core technology to improve the quality of operations, enabling preliminary study of various operational conditions through simulation, understanding of operational conditions through IoT sensing, and detailed information during operation of technical systems through simulation based on sensing data. The digital twin technology is expected to become a core technology to improve the quality of operations.

1D Simulation

In the simulation of specific products such as automobiles or industrial domains, advanced simulation methods such as multi-domain simulation, in which the piping system and 3D layout design interact, and multi-scale multi-physics, in which the properties of structural materials are evaluated from the microstructure of the materials, are also being incorporated. In the case of engines and propellers, the analysis of a single unit of material is used. In the case of an engine and propeller, it is more desirable in practice to evaluate the performance of the two as a systemized propulsion mechanism than to evaluate the performance of a single unit. This is because an engine that is excellent on its own may not be the best option depending on the propeller it is combined with. In designing technical systems that are more complex than an engine and propeller and that combine many elements, it is very useful to use simulation to predict the behavior of the system until its functionality is realized.

　Although there does not seem to be a clear and common definition of 1D simulation, many academic papers refer to boundary value problems for ordinary differential equations as 1D models, and 1D simulation is considered to be based on this 1D model(see the reference). Therefore, we believe it is appropriate in the engineering field to define 1D simulation as a simulation by modeling like ordinary differential equations (1D) focusing on the time axis in the design process for system behavior, such as functions, of complex systems expressed in multiple dimensions. In general, 1D simulation is a simulation that we would like to design.

　In general, 1D simulation models the performance characteristics and their interaction with respect to the functionality to be designed. If we focus only on propellers and engines, we model mainly the forces transmitted through the shafts, and the details such as whether the engine and propeller fit in the vessel or pumps are considered separately. There are also design processes that can be integrated with CAD, FEM, etc. to enable CAE.

　The concept of 1D simulation will accelerate the use of simulation technology in decision making regarding the design of increasingly complex industrial products and services.

複雑なシステムの挙動予測

シミュレーションモデル

複雑なシステムの挙動を予測するためには、現実世界の物理現象、社会現象をシミュレーションモデルとしてモデル化します。定性的なモデリングを通じた対象システムの理解から始めるため、モデルの構築には多くの時間が必要となり、また、シミュレーション手法には基本的なものを利用します。一方で、対象システムや注目している意思決定項目に影響を与える感度の高い要素や、下のキーワードのようなシミュレーションモデルの型等の選定には配慮が必要です。

• 離散イベントシミュレーション、連続型シミュレーション、マルチエージェントシミュレーション

• イベント指向、プロセス指向、オブジェクト指向

• 時間駆動、イベント駆動

機械学習の利用

システムの挙動予測への機械学習の利用では、多くの場合分類や回帰を用います。実社会や産業界のシステムについて十分な教師データが得られることは少ないため、多くの場合、学習したモデルの評価方法に工夫が必要になります。

社会システムの課題解決のためにモデリングを行う場合、先端的なアルゴリズムに関する知識量よりも、対象とする問題の複雑さや特徴を、データとして扱うための課題定義や問題に適したアルゴリズムの選定が重要になります。扱うデータが連続量なのから離散量なのか、分布はパラメトリックとすべきかノンパラメトリックとすべきか、ドメイン知識と機械学習やデータサイエンス系の知識の両方が必要になります。この観点で機械学習を学ぶため、研究室では識別器の設計というコンテクストで機械学習系の知識を説明しているDuda らの教科書を採用しています。

ハイブリッド手法

シミュレーションと機械学習による挙動予測や、さらに定性的な分析結果から得られる知見をルールベースを用いたハイブリッド手法では、個別の対象システムへの特化が必要になるものの再現性の高い挙動推定が可能になりえます。

Predicting the behavior of complex systems

Simulation Models

To predict the behavior of complex systems, we model real-world physical and social phenomena as simulation models. Since we start with an understanding of the target system through qualitative modeling, a lot of time is required to build the model, and we use basic simulation methods. On the other hand, consideration must be given to the selection of sensitive factors that affect the target system and the decision items of interest, as well as the type of simulation model, such as the keywords below.

• Discrete event simulation, continuous simulation, multi-agent simulation

• Event-oriented, process-oriented, object-oriented

• Time-driven, event-driven

Use of Machine Learning

The use of machine learning to predict system behavior often involves classification and regression. Since sufficient teacher data on real-world or industrial systems is rarely available, in many cases, ingenuity is required in how to evaluate the learned models.

When modeling to solve social system problems, it is more important to frame the problems and select the appropriate algorithm for the problem than to have a large amount of knowledge about advanced algorithms. Whether the data to be handled is a continuous or discrete, whether the distribution should be parametric or nonparametric, and whether both domain knowledge and knowledge of machine learning and data science are required. To learn machine learning from this perspective, we have adopted a textbook by Duda et al. that explains machine learning-related knowledge in the context of desiging classification systems.

Hybrid Methods

Hybrid methods that use simulation and machine learning to predict the behavior of a system, or that use a rule base of findings from more qualitative analysis, can provide highly reproducible behavior estimation, although they require specialization to the individual system of interest.

システム思考の適用

システム思考ワークショップ

　製品やサービス、技術についての新しい着想を創出し、洗練させるプロセスにシステム思考のツールや考え方は有効です。サービスやシステムが利害関係やニーズを満たすメカニズムをダイアグラム等に書き起こすことで、現在稼働しているシステムや検討中の新しいシステムについての認識を共通化できます。このプロセスには、専門が異なるメンバー（営業部門と技術部門など）によるワークショップが有効です。

インタラクティブシミュレーション

　システムを組み合わせることでサービスが実現されていると、システム間の影響の伝播によりサービスに対する変更が期待通りの効果を示さなかったり、新しい問題を引き起こすこともあり得ます。システム思考的なアプローチによりシステム間の相互作用を想定し、ある程度定量的な挙動予測を行うシミュレーションをユーザーインターフェースとともに提供することで、このような状況におけるシステムの応答を検討することができます。このようなインタラクティブなシミュレーション環境により、個人の知識や経験を超えた大規模で複雑なシステムに関する意思決定を支援できます。

技術駆動型トランスフォーメーション

　企業や組織のオペレーションは複雑であるため、新技術導入、組織変更、製品開発プロセス革新などの技術駆動型トランスフォーメーション（≒デジタルトランスフォーメーション）の効果は不確実性を伴います。情報技術の導入においてはPoC(Proof Of Concept)による解決が期待されていますが十分ではありません。

　例えば、輸送システムにおいて新しいセンサー導入等による故障率改善などの効果が、影響伝播や創発的効果を通じて輸送システム全体にどのような効果を及ぼすかを見積もることは困難です。実務上は、センサーを導入するだけではなく、輸送機器のメンテナンスをスケジュールベースからコンディションベースに変更するなどの関連部門のプロセス変更を含めることでより大きな効果があると期待されますが、プロセス変更の負荷の特定の部門への偏りや、技術自体の成熟度による不確実性のために導入効果の予測はより困難になります。システム思考のフレームワークにより組織全体をシステムとして捉えることで、組織を取り巻く利害関係、導入する技術の特性、必要なプロセス変更を含めた検討を明示的に行い、トランスフォーメーションのビジョン策定を支援することでこれらの問題を解決できます。

産業におけるシステム思考

システム思考の基本的な考え方は、通常多くの産業ドメインに組み込まれています。具体的には、利害関係の問題解決や技術を効率的な活用のための知識が業界のガイドラインや商習慣などの形で利用されています。システム思考はこれらの考え方を一般化したものであり、特に成熟産業では新しい考え方ではありません。一方で、デジタルトランスフォーメーションや産業界の脱炭素化などの変革期では、一般化された記述により問題点を整理し、解決に向けた活動を実行可能な形に定義することが必要となります。このためにシステム思考の考え方が必要になります。

Applications of Systems Thinking

Systems Thinking Workshop

 Tools and ideas of systems thinking are useful in the process of creating and refining new ideas about products, services and technologies. By transcribing the mechanism how those services and systems meet their interests and needs, a common understanding of the systems currently in operation and new systems under consideration can be shared. Workshops by members with different specialties (such as sales and technical departments) are useful for this process.

Interactive Simulations

When services are realized by combining systems, changes to the services may not be as effective as expected due to the propagation of impacts between systems, or may cause new problems. By providing a simulation that assumes the interaction between systems by a system thinking approach and predicts behavior quantitatively to some extent together with the user interface, the response of the system in such a situation can be predicted. The interactive simulation environment can support decision making process of large and complex systems that go beyond your personal knowledge and experience.

Technology-driven Transformation

Due to the complexity of corporate and organizational operations, the effects of technology-driven transformation (≒ digital transformation), such as the introduction of new technologies, organizational change, and product development process innovation, are subject to uncertainty. In the introduction of information technology, solutions based on Proof Of Concept (POC) are expected, but they are not sufficient.

For example, it is difficult to estimate what effect the introduction of a new sensor will have on the entire transportation system through propagation of influence and emergent effects. In practice, it is expected that not only the introduction of sensors but also process changes in related departments, such as changing the maintenance of transportation equipment from schedule-based to condition-based, will have a greater effect. However, it is more difficult to predict the effect of implementation due to the unevenness of the burden of process change on certain departments and the uncertainty caused by the maturity of the technology itself. By looking at the entire organization as a system through the framework of systems thinking, these problems can be solved by explicitly considering the interests surrounding the organization, the characteristics of the technology to be introduced, and the necessary process changes, and by supporting the formulation of a vision for transformation.

Systems thinking in industry

The basic idea of systems thinking is usually embedded in many industrial domains. Specifically, knowledge for solving stakeholder issues and efficient use of technology is used in the form of industry guidelines or business practices. Systems thinking is a generalization of these ideas, not a new one, especially in mature industries. On the other hand, in the transformational period such as digital transformation and decarbonization of industry, it is necessary to sort out problems by generalized description and define the activities for solving them in a feasible form. This requires the idea of systems thinking.

雑記

人間を含む複雑なシステムについて、シミュレーションモデルによる結果は多くの場合誤りを含んでいると考えます。一方で、分野の異なる専門家の知識を組み込んだモデルを用いてシステムの挙動を推定したうえで意思決定を行うというプロセスは、誤りを含んでいたとしても、最も思慮深い意思決定方法であり、意思決定にかかわった専門家の専門性を生かした最良の決定が得られると考えています。

システム思考やシステムズエンジニアリング、システムダイナミクスで用いられるダイアグラム等により企業の問題を記述すると、問題の原因や解決策を明らかにできることもあります。これらの問題や解決策は、利害関係者にとって望ましくない事実であることも多くあります。発見した問題解決を組織に提案し、実現するためには、十分な配慮とともに適切な利害関係者に展開する必要があります。（特定の事業部の将来性がないことや、特定のプロジェクトの失敗をシステム思考による分析で明らかにした場合、事業部の売却やプロジェクトのキャンセルといった解決策は最適であってもなかなか実行されない。）

Miscellaneous notes

We believe that simulation model results for complex systems involving humans are often erroneous. On the other hand, we believe that the process of making decisions based on estimating system behavior using models that incorporate the knowledge of experts from different fields is the most thoughtful decision-making method, even if it contains errors, and that the best decisions are obtained by utilizing the expertise of the experts involved in the decision-making process.

By describing a company's problem through diagrams used in systems thinking, systems engineering, and system dynamics, it may be possible to clarify the cause and solution of  problems. These problems and solutions are often undesirable facts for stakeholders. In order to propose and realize the problem-solving that you find, you need to be considerate and deploy it to the right stakeholders. (When you find a business unit no potentials or a project likely to fail through a system-thinking analysis, solutions such as selling the division or canceling the project are not easily implemented.) 

研究室より

1. E.クロウリー, B.キャメロン, D.セルヴァ(著), 稗方和夫（訳）：システム・アーキテクチャ: 複雑システムの構想から実現まで, 丸善出版, (2020)

2. 稗方和夫, 髙橋裕：システム思考がモノ・コトづくりを変える デジタルトランスフォーメーションを成功に導く思考法,  日経BP, (2019)

参考書

2. 1. E. Crawley, B. Cameron and D. Selva, System Architecture: Strategy and Product Development for Complex Systems, Pearson, 2016.

   2. NASA Systems Engineering Handbook (SP-2016-6105), Rev 2

   3.  J. D. Sterman, "Business Dynamics: Systems Thinking and Modeling for a Complex World ", McGraw-Hill, 2000.

   4. INCOSE, INCOSE webpage, https://www.incose.org/systems-engineering, accessed on Oct 13 2020

   5. What’s an Engineered System?, Engineering Research Center/NSF webpage, https://erc-assoc.org/content/what%E2%80%99s-engineered-system, accessed on Feb 4 2021

   6. Paté-Cornell, M. E. (1996). Uncertainties in risk analysis: Six levels of treatment. Reliability Engineering and System Safety, 54(2–3), 95–111. https://doi.org/10.1016/S0951-8320(96)00067-1

   7. 1D model, "https://www.sciencedirect.com/topics/engineering/1d-model", accessed on June 27, 2022

   8. Cameron, B., & Adsit, D. M. (2020). Model-Based Systems Engineering Uptake in Engineering Practice. IEEE Transactions on Engineering Management, 67(1), 152–162. https://doi.org/10.1109/TEM.2018.2863041

   9. リチャード・O．デューダ (著), ピーター・E．ハート (著), デイヴィット・G．ストーク (著), 尾上守夫(監修), 江尻公一　ほか(訳)(2001), パターン識別 [原書 Pattern Classification], https://acm-book.shop/?pid=19413728 

Our publications

1. "Systems Architecture: From Conceptualization to Realization of Complex Systems" by E. Crowley, B. Cameron, D. Selva, translated by K. Hiekata, Maruzen Publishing Co.

2. "Systems Thinking for Successful Digital Transformation" by K. Hiekata and H. Takahashi, Nikkei Business Publications, Inc.

References

1. E. Crawley, B. Cameron and D. Selva, System Architecture: Strategy and Product Development for Complex Systems, Pearson, 2016.

2. NASA Systems Engineering Handbook (SP-2016-6105), Rev 2

3.  J. D. Sterman, "Business Dynamics: Systems Thinking and Modeling for a Complex World ", McGraw-Hill, 2000.

4. INCOSE, INCOSE webpage, https://www.incose.org/systems-engineering, accessed on Oct 13 2020

5. What’s an Engineered System?, Engineering Research Center/NSF webpage, https://erc-assoc.org/content/what%E2%80%99s-engineered-system, accessed on Feb 4 2021

6. Paté-Cornell, M. E. (1996). Uncertainties in risk analysis: Six levels of treatment. Reliability Engineering and System Safety, 54(2–3), 95–111. https://doi.org/10.1016/S0951-8320(96)00067-1

7. 1D model, "https://www.sciencedirect.com/topics/engineering/1d-model", accessed on June 27, 2022

8. Cameron, B., & Adsit, D. M. (2020). Model-Based Systems Engineering Uptake in Engineering Practice. IEEE Transactions on Engineering Management, 67(1), 152–162. https://doi.org/10.1109/TEM.2018.2863041

9. Richard O. Duda (Author), Peter E. Hart (Author), David G. Stork (Author) (2000), Pattern Classification 2nd Edition, https://www.wiley.com/en-us/Pattern+Classification%2C+2nd+Edition-p-9781118586006