日本船舶海洋工学会 2022 年度秋季講演会

完全自律航行船の設計・開発・実証のための DFFAS コンソーシアムのアプローチ— MBSE と MBD を活用した自律航行システムの構築 —2022/11/18
41
株式会社 MTI 2 東京大学大学院 3 日本無線株式会社
古野電気株式会社 5 株式会社日本海洋科学 6 日本郵船株式会社

暮田留依1 ，中島拓也 2 ，樋口穣司 3 ，西山尚材 3 ，柳原智哉 4 ，櫻井美奈 5 ，西村遥 6 ，沓名弘二 6 ，中村純 1

目次
1. はじめに： DFFAS プロジェクトの概要
2. 完全自律航行システム開発のアプローチ：モデルを活用した開発フロー
3. 設計フロー：システムの要求洗い出しとモデル構築
4. 検証フロー：モデルを起点としたシミュレーションの活用
5. おわりに©2022. MTI CO., Ltd. All rights reserved.

2 / 22

1. はじめに： DFFAS プロジェクトの概要
2. 完全自律航行システム開発のアプローチ：モデルを活用した開発フロー
3. 設計フロー：システムの要求洗い出しとモデル構築
4. 検証フロー：モデルを起点としたシミュレーションの活用
5. おわりに©2022. MTI CO., Ltd. All rights reserved.

3 / 22

日本財団 MEGURI2040 プロジェクトと DFFAS コンソーシアム
背景：内航海運を取り巻く環境 → ヒューマンファクターを補完する運航の高度化・自律化が必要
I 船員の高齢化
I 海難事故：約 8 割がヒューマンエラーに起因日本財団 無人運航船プロジェクト MEGURI2040

I 2022 年までに無人運航船の実証実験を実施 → 無人運航船の実用化による内航海運の課題解決を目指す

DFFAS （Designing the Future of Full Autonomous Ship）コンソーシアム

I NYK グループを含む国内約 30 社（国外協力企業を含むと約 60 社）による Open Innovation 体制
I MEGURI2040 「無人運航船の実証実験にかかる技術開発共同プログラム」に参画

DFFAS コンソーシアム 参画企業（国内）©2022. MTI CO., Ltd. All rights reserved.

4 / 22DFFAS コンソーシアムの取り組みと本講演の対象
DFFAS コンソーシアムの成果：輻輳海域を含む完全自律航行に対応したシステムの構築と実証
APExS-auto：Action Planing and Execution System for full autonomous
I DFFAS コンソーシアムで開発した完全自律航行システムの概念設計
I ClassNK および BV より基本設計承認（AiP）取得 @ 2022/03

完全自律航行システム
APExS-auto

本船

実証航行のイメージ@ 株式会社イコーズ
749GTコンテナ船「すざく」

陸上支援センター

幕張
Fleet Operation Center

東京港

浦賀水道航路を含む

津松阪港

伊良湖水道航路を含む

往復
424 NM (790km)

DFFAS における実証航行のイメージと陸側・船側システムの概要

本講演の対象： DFFAS における完全自律航行システム（APExS-auto）設計・検証のアプローチ©2022. MTI CO., Ltd. All rights reserved.

5 / 22

1. はじめに： DFFAS プロジェクトの概要
2. 完全自律航行システム開発のアプローチ：モデルを活用した開発フロー
3. 設計フロー：システムの要求洗い出しとモデル構築
4. 検証フロー：モデルを起点としたシミュレーションの活用
5. おわりに©2022. MTI CO., Ltd. All rights reserved.

6 / 22

大規模システムとしての自律航行システムとモデルの必要性
APExS-auto の特徴：深い機能階層，複雑な相互作用（機械-機械，機械-人） etc.
→ System of Systems (SoS) として構成される自律システム
SoS の開発範囲特定や設計・検証過程で適切にシステム分割・統合を行うのに必要なのは…
I 設計・検証の階層間でのシステム仕様や特性等の網羅性・連続性担保
I 多数の関係者間での共通言語によるシステム仕様や特性の表現：モデル の導入
APExS-auto サブシステム構成
サブシステム名
役割

Propulsion
Communication
Central Information
Management (CIM)

ユーザー目線で達成すべきシステム特性
統合抽出

モデル（群）

設計
レイヤ1

航行計画を策定し船の動きを制御
動力・電力を管理
船陸間通信モデル（群）
抽象化

...

Maneuvering

ユーザーの課題
ユースケース etc...

システムの状態を管理

モデル
（群）

設計
レイヤn

抽象化

分解 抽象化

入力
出力

要求
安全証明

抽出

設計
レイヤ2

入力
出力

要求
安全証明

抽出

入力
出力

要求
安全証明

検証

階層的な SoS 構築フローとモデルの活用©2022. MTI CO., Ltd. All rights reserved.

7 / 22

モデルを活用したシステム/SoS 開発と V-Process の考え方
モデル：システムの仕様や特性の共通言語（SysML 等）による抽象表現

I SoS のあり様を示す体系的な仕様書
I 開発での活用： MBSE (Model Based Systems Engineering)， MBD （Model Based Design）

V-Process：階層単位でシステムの設計と検証を対で捉える開発工程のモデル

I ConOps （Concept of Operations）：システム享受者の目線で記述される上位要求
I 設計：要求に従い，システムのスコープや階層を逐次分割しながらコンポーネントを構築
I 検証（Verification）：システムが要求に対して正しく実現されているか
I 妥当性確認（Validation）：正しいシステムであるかどうか（ConOps との照合）

V-Process におけるモデルの有効利用

I システム機能設計を階層的に透明化
I IMO ルールや船級規則等との整合性の根拠：
Goal Based Standards との相性

Concept of Operations
開発
フェーズ

検証
フェーズ

概念
設計

全体
試験

基本設計

結合
試験

Validation
詳細
設計

モデル（群）

設計

抽象化

抽出

単体
試験

入力
出力

V-Process におけるモデルの位置付け（イメージ）©2022. MTI CO., Ltd. All rights reserved.

8 / 22

1. はじめに： DFFAS プロジェクトの概要
2. 完全自律航行システム開発のアプローチ：モデルを活用した開発フロー
3. 設計フロー：システムの要求洗い出しとモデル構築
4. 検証フロー：モデルを起点としたシミュレーションの活用
5. おわりに©2022. MTI CO., Ltd. All rights reserved.

9 / 22

自律航行システムの要求分析： ConOps を起点とした上位設計モデルの導出
DFFAS で策定した自律航行システムの ConOps （抜粋）
I 背景と目的：認知・分析・計画・実行の各タスクの自律化と高度支援による内航船の安全性向上
I 前提
I 装備の対象：内航コンテナ船（749GT）
I 本船乗組員が介入することなく Berth to Berth の航行が可能（Lloyd 自律船レベル AL4 相当）

I 機能分担I 人間の役割：陸上での長期計画策定・承認，ステータス承認，遠隔支援
I 機械の役割：離桟〜着桟までの航行のための認知・分析・計画・実行機能，陸上での高度支援（等）自律航行システムの上位設計を構築するための要求を ConOps から抽出
I 機能の視点I 長期・広範囲，短期・周囲の環境情報を認知しながら航行計画を策定・実行可能I 安全維持：衝突・座礁に至るリスクの抑制

I 構成の視点
I 本船上では機械により一連のタスクを実行
I 陸上に要員を配置し支援・承認を実施©2022. MTI CO., Ltd. All rights reserved.

10 / 22

自律航行システムの最上位モデル：機能MBSE の考え方：機能 = 要求をもとにシステムのふるまいを抽出したモデル
機能ブロック：環境とシステムとの相互作用を時間軸に応じて分類

I Strategic function：及ぼす影響が長期に渡る機能
I Tactical function： Strategic function の出力を遂行するための短期的な機能
I Operational function： Tactical function を遂行するための極めて頻繁に繰り返される機能

機能フロー：自律航行システム上での計画策定→離桟→着桟 までの一連の流れを表現
surrounding
environment

wide-range environment

Human
restriction

LOED & LERPP
長期環境情報収集・統合
長期計画の策定

LOED: Long term Object and Event Detection
SOED: Short term Object and Event Detection

Strategic Function Loop (shore)
Human
Intension
LOEDOperational Function Loop
L-Event Response andPath Planning

Human:Propulsion operationcommand

START

Human onboard:
Oiler

HumanApproval

自船
統合情報

航海計画

行動計画

ANDAND

END

Propulsion & Power

Tactical Function Loop
Maneuvering

S-Event Response andPath Planning

Track Control (TC)
Heading Control (HC)Actuator

Vessel motion

Propulsion
Speed Control (SC)Communication

Attitude Control (DPS)

統合情報

Basic vessel motion control

SOED & SERPP
短期環境情報収集・統合
行動計画の策定

SOEDCommunication(Service; backend for subsystems,: network/physical layer)

行動計画

transmitting systemcommunication data (packet)

shore-onboard communication:communication path selection, traffic control
security(authentication/permission), QoS

System Status Management
Health Check (each subsystem)
CIM+subsystems

Error & Fail Detection

Confirmation of the
Sub-System Heal
Level

CIM
Integrate and Confirm
the System Status

CIM
システムのステータス/
ODD管理

DTC
行動計画の実行

Humanapproval

自律航行システムの機能ブロック©2022. MTI CO., Ltd. All rights reserved.

自律航行システムの機能フロー
11 / 22

自律航行システムの最上位モデル：構成
MBSE の考え方：構成 = 機能の割当先を表現するモデル
ConOps からブレークダウンされた要求をもとに，船/陸 と 機械/人 の配置や役割を表現
I Strategic function （長期の航海計画策定等）：陸上で人間（陸上船長）の承認のもと機能
I Tactical function：船/陸のコンポーネント間で情報同期しながら透過的に機能
I Operational function：船上で機能→ サブシステム構成を境界として機能をコンポーネントにマッピングH&M in charge @ Status: Normal/AM

APExS-auto system
Vessel (Onboard)

AshoreFOC (ashore)

Certified captain,
Certified chiefengineer

Subsystem: Propulsion
Primary

Subsystem:
Communication

Oiler

Secondary

Restrictor

CIM

Administrator

SecondaryOperatorstatus ack/approval
input restriction
providing/modifying plan
emergency operation

自律航行システムの構成©2022. MTI CO., Ltd. All rights reserved.

LERPP
Approver & Planner

Certifiedchief engineer

Certified captain(AM; monitoring only)

SERPP Planner(propulsion)

SERPP Planner(maneuvering)

Oiler

DTC

Certified captain,
Certified chiefengineer

SecondarySubsystem: Maneuvering
Primary

Certified captain,Certified chiefengineer

Certified chief engineer

Subsystem: CIM
Primary

CIM Approver

Human / Machine
OnBoard

自律航行システムの権限/役割の割当（例）12 / 22

自律航行システムの最上位モデル： STAMP/STPA による安全性評価の視点
SoS の安全性：アイテム単位の積み上げでは網羅的・包括的な脅威の影響度評価が困難
STAMP/STPA：機能間の相互作用を起点とする大規模システムの安全解析手法
I 分析対象の系と環境における相互作用をトップダウン的に解析したモデル：コントロールストラクチャ
I モデルの粒度： SoS が安全を維持するための制約（安全制約）を実現する視点で設定

APExS-auto における安全制約の設定

I 衝突・座礁：自律航行システムとして回避すべき最終事象
I 最終事象回避のために維持されるべき制約群とシーケンス：自律運航船と有人船とのリスク比較の横串
Failure detection (not provided)
Prevention of improper output(Providing cause hazard, Too early/Too late, Stop too soon/late)intermediate events

SC4: Obtaining static
constraints
Analysis
SC3: Detecting naturalenvironments
Detection

SC9: Analyzing external
constraints (EODD)
AnalysisCIM（船）

ODD

Consequence

Events triggeringconsequences

SC8:
Analyzing internal
constraints (IODD)
Detection/Analysis/
Planning/Execution

情報同期・統合

SC6:
Controlling
Execution

Close toobjects/othervessels/No-go area

SC2: Detecting other vessels
and those state
Detection
SC5: Establishingnavigation or actionPlanningplan

SC7: Detecting geographic
information on areas tonavigate
Detection

安全制約群の関係©2022. MTI CO., Ltd. All rights reserved.

制約

情報同期・統合

Loss ofseaworthiness

確定ステータスCollision
GroundingSC1: Detecting own vesselstates
Detection

CIM
（陸）

SERPP
（船）
情報同期・統合

APExS-auto のコントロールストラクチャ（抜粋）13 / 22

STAMP/STPA と BowTie 分析によるリスクの可視化
APExS-auto のアプローチ：STAMP/STPA と BowTie 分析の統合によるリスクアセスメント
I BowTie 分析：システムの脅威と中間/最終事象の流れ と それらに対する防御策を分析するフレーム
I コントロールストラクチャをもとに抽出した脅威を起点に BowTie 分析を実施
I 上位設計モデルを起点としたリスクアセスメント → システムの基本要求抽出 のフローを構築
UCAs fromSTPA脅威に対する防御策

中間事象

最終事象

APExS-auto におけるコントロールストラクチャと BowTie 分析の統合（抜粋）

一連のリスクアセスメント結果：設計や実証オペレーションに反映
I 防御策：システムに対する安全維持観点での基本要求
I FMEA：安全制約を軸に影響度の評価 & 対策の策定©2022. MTI CO., Ltd. All rights reserved.

14 / 22

V-Process に沿ったモデルベース設計：詳細設計に至る機能要求の洗い出し
上位設計から詳細設計へのブレークダウン
I 詳細設計：ドメインや機能階層に応じて上位のモデルを連続的に分割・詳細化
I システム要求の体系的な洗い出しが必要

機能要求抽出と安全論証のフレーム： GSN （Goal Structure Notation）

I 論証すべき（サブ）ゴールとその論拠（議論の軸）を順次ツリー状に表現：要求の構造化
I DFFAS における利用：設計として課される要求と機能全体の洗い出しに活用
I 機能を網羅するための上位の軸：サブシステム/安全制約（; 機能分類）/機能の時間軸

Goal:システム（機械）と人間（承認者，オペレータ）による安全な航行の実現

Strategy:
システムによって実行されるタスクにおけるリスクの軽減

Goal:システムと人（承認者）による決定（適切なI/F）

Goal:
設計：システムによる状況認識・判断・実行

GSN の例：設計要求の洗い出し

Goal:
DTCの役割を網羅

Strategy:
制御の実行に関する完結性を網羅（制御対象）

Goal:
船体姿勢

DPS
性能基準

Goal:
航路

TCS
性能基準

Goal:
船速（回転数）

Speed
Pilot
性能

GSN の例：制御機能の洗い出し©2022. MTI CO., Ltd. All rights reserved.

15 / 22

モデルの例：システムの状態管理（CIM）
CIM （Central Information Management）

I ODD （Operational Design Domain）：運行設計領域，自動化/自律化システムが適切に機能する範囲
I コンポーネント群の健全性情報をもとに自律航行システム全体のステータス = ODD 境界を判断
I Normal：正常動作
I Active Monitoring：人間の監視を前提にシステムが動作I Remote Fallback：人間がシステムに介入し航行を維持（承認の下でシステム→人に操船権を移譲）
I Independent Fallback：システムが安全を維持するための動作

機能フロー図と N2 図により CIM が実行するステータス判定・移行のロジックをモデリング
Error & Faildetection@Maneuvering

Error & Faildetection@Propulsion

Error & Faildetection@Communication

fixing health level(Maneuvering)

fixing health level(Propulsion)

fixing health level(Communication)collectingsubsystem healthlevels

ITSOED@ each subsystems

Error & failinformation
working condition

fixing subsystem
health level@ each subsystems

subsystem healthlevels

collectsystem healthstatussubsystem healthlevels

LPrequesting:status override(human)

judging temp wholesystem status
Status override request(by human @ FOC)

OR
triggering
ack/approval
request & waiting
ack/approval
statusapproval/ack
escaration
OR (timeout)

Status approval/ack(by human @ FOC)

LPstatus
approval/ack
within preset timesynchronizing: fixedwhole systemstatusIT

Maneuvering(SERPP)

Communication(SERPP)

temp wholesystem status

temp wholesystem status

triggering
triggering & waiting
ack/approval
status approval
request & waiting
requestack/approval

temp wholesystem statusapproval/ack
information

approving/ack:
approving:
temp whole systemstatus(human)approval/ack

fixing fixed wholesystem status

Propulsion(SERPP)CIM の機能フロー図©2022. MTI CO., Ltd. All rights reserved.

status to beoverrided

judge temp wholesystem status

fixed wholesystem status

synchronizing(whole)system status

CIM の N2 図：機能間 I/F の表現
16 / 22

1. はじめに： DFFAS プロジェクトの概要
2. 完全自律航行システム開発のアプローチ：モデルを活用した開発フロー
3. 設計フロー：システムの要求洗い出しとモデル構築
4. 検証フロー：モデルを起点としたシミュレーションの活用
5. おわりに©2022. MTI CO., Ltd. All rights reserved.

17 / 22

モデルベースのシステム検証と V-Process
V-Process に沿ったモデルベースのシステム検証FMU

FMU

FMU

FMU

FMU

FMU

FMU

I 下位の検証を網羅的に実施→上位工程での手戻りを抑制可能
I シミュレーションの活用（バーチャルエンジニアリング）
I 検証対象への作用や実環境の入出力を再現可能

I モデルによるシステムロジックの記述
I 機能粒度と検証範囲・境界の対応付け
I 柔軟な HIL/MIL テスト
I SoS のコミッショニングの効率化

FMU （Function Mockup Unit）

FMU の組合せによるシミュレーション（イメージ）

I Open Simulation Platform 上で組み換え可能なモジュールの標準形式
I 自動車業界のモデルベース開発における活用実績

DFFAS コンソーシアムでの検証のアプローチ：評価対象の機能や周辺環境のモデルを FMU 化→ FMU や実機を柔軟に統合しながら V-Process を遂行（MIL テスト/HIL テスト）

©2022. MTI CO., Ltd. All rights reserved.

18 / 22

シミュレーション環境の活用： MIL テストの事例
External ODD （EODD）：外部環境要因に基づく自律航行システムの ODDI 自船周囲の環境情報をもとに判定
I Maneuvering 健全性情報として CIM に配信→ ODD 内外（ステータス）を判断

シミュレーションプラットフォーム上での MIL テストによる EODD 設定の算出
I 本船に作用し得る外乱条件（風/波/潮流）のモデル：本船周囲環境の模擬
I 航路制御機能のモデル：簡易的な航路追従制御の模擬I 自船運動のモデル：低速域/離着桟操船を含む船体運動の模擬→ 複数の外乱条件の組合せで擬似的な航行を繰り返し実行し判定用の設定値を算出

シミュレーション画面の例©2022. MTI CO., Ltd. All rights reserved.

EODD 表示例（古野電気提供）
19 / 22

シミュレーション環境の活用：全体構成と HIL テストの事例
陸上で構築したシミュレーション環境
I 周辺環境のモデル（例）：他船の AIS 信号を模擬するシナリオ→自動避航機能も評価
シナリオ管理環境条件（風/波/潮流）船モデル

HILテスト構成

模擬センサ
GPS/方位/風向風速etc.

自船情報 自律運航システム（検証対象）

MotionMILテスト構成他船船体モデル（FMU）

地理情報

Motion

制御機
FMU

Thrust/Rudder

アクチュエータモデル（プロペラ/舵）制御指示

シミュレーション環境の構成

シミュレーション検証の様子

システムのモデルに基づいた検証項目の抽出 → 30 項目以上の不具合を本船搭載前に解消
I 自律航行システムの機能シーケンス：正常系シナリオの網羅
I STPA 分析に基づくコントロールストラクチャ：異常系シナリオの網羅©2022. MTI CO., Ltd. All rights reserved.

20 / 22

1. はじめに： DFFAS プロジェクトの概要
2. 完全自律航行システム開発のアプローチ：モデルを活用した開発フロー
3. 設計フロー：システムの要求洗い出しとモデル構築
4. 検証フロー：モデルを起点としたシミュレーションの活用
5. おわりに©2022. MTI CO., Ltd. All rights reserved.

21 / 22

まとめ
日本財団 無人運航船プロジェクト MEGURI2040 における DFFAS コンソーシアムの取り組み
I 完全自律航行システム APExS-auto の構築と実船による輻輳海域での無人運航実証に成功

APExS-auto の構築におけるモデルの活用と V-Process の導入→ 連続的なシステム要求の洗い出し & マッピング，フロントローディング

I ConOps：使用者目線でのシステム特性・スコープ等のドキュメンテーション
I 設計フェーズ： ConOps を起点にシステムの要求を洗い出し，様々な視点からモデルを構築
I 検証フェーズ：モデルを起点とした検証項目の抽出とシミュレーション環境構築

リスクアセスメント：モデルを起点とした大規模システムに対応可能なアプローチの導入
I STAMP/STPA と BowTie 分析の統合 → 安全のための要求を抽出し設計にフィードバック← DFFAS コンソ―シアム ドキュメンタリー映像©2022. MTI CO., Ltd. All rights reserved.

22 / 22