平成30年度（第18回）電子航法研究所研究発表会㸯㸱㸬)),&( ᳨ドᐇ㦂ࡢሗ࿌࡜ศᯒ
㸯㸬ᑠᆺ↓ேᶵࡀ㣕⾜ࡍࡿ✵ᇦ࡟࠾ࡅࡿ⯟✵ᶵ㐠⯟࡟㛵ࡍࡿ⪃ᐹ
┘ど㏻ಙ㡿ᇦ ͤ࿅ ᬡᮾ㸪ྂ㈡ ⚞㸪ఫ㇂ Ὀே⯟✵஺㏻⟶⌮㡿ᇦ ͤᖹᯘ༤Ꮚ㸪⹡㇂኱ᆅ┘ど㏻ಙ㡿ᇦ ἙᮧᬡᏊsame time. Therefore, the impact of FF-ICE changesࠗࡇࡢἲᚊ࡟࠾࠸࡚ࠕ↓ே⯟✵ᶵࠖ࡜ࡣ㸪⯟for
ASPs, particularly relative to adjacent Flight✵ࡢ⏝࡟౪ࡍࡿࡇ࡜ࡀ࡛ࡁࡿ㣕⾜ᶵ㸪ᅇ㌿Information Regions (FIRs) and AUs, is unknown and⩼⯟✵ᶵ㸪⁥✵ᶵ㸪㣕⾜⯪ࡑࡢ௚ᨻ௧࡛ᐃ
unpredicted
at this time.
ࡵࡿᶵჾ࡛࠶ࡗ࡚ᵓ㐀ୖேࡀ஌ࡿࡇ࡜ࡀ࡛
To validate the ICAO provision changes forࡁ࡞࠸ࡶࡢࡢ࠺ࡕ㸪㐲㝸᧯సཪࡣ⮬ື᧯⦪
potential implementation, accounting for operational㸦ࣉࣟࢢ࣒ࣛ࡟ࡼࡾ⮬ືⓗ࡟᧯⦪ࢆ⾜࠺ࡇand technical interactions between different ATM࡜ࢆ࠸࠺ࠋ㸧࡟ࡼࡾ㣕⾜ࡉࡏࡿࡇ࡜ࡀ࡛ࡁࡿ
systems within Air Navigation Service Providersࡶࡢ㸦ࡑࡢ㔜㔞ࡑࡢ௚ࡢ஦⏤ࢆ຺᱌ࡋ࡚ࡑ(ANSP) and AU domains, the Internationalࡢ㣕⾜࡟ࡼࡾ⯟✵ᶵࡢ⯟⾜ࡢᏳ඲୪ࡧ࡟ᆅ
Interoperability Harmonization and ValidationୖཬࡧỈୖࡢேཬࡧ≀௳ࡢᏳ඲ࡀᦆ࡞ࢃࢀ
(IIH&V) project has been conducted by Federalࡿ࠾ࡑࢀࡀ࡞࠸ࡶࡢ࡜ࡋ࡚ᅜᅵ஺㏻┬௧࡛Aviation
Administration㸧ࢆ࠸࠺ࠋ(FAA). Threeᐃࡵࡿࡶࡢࢆ㝖ࡃࠋ
࠘ Validation
Exercises consisting of Tabletop and Lab exercises are

1. ࡣࡌࡵ࡟
INTRODUCTION
1 The
ᖹᡂFlight
27 ᖺ
12Flow᭶࡟⯟✵ἲࡢᨵṇࡀ᪋⾜ࡉࢀandInformation for a Collaborative࡚࠿ࡽ2
ᖺ㏆ࡃࡀ⤒㐣ࡋ㸪ከࡃࡢ↓ே⯟✵ᶵ
Environment (FF-ICE) is a System Wide Information࣮ࣘࢨ࣮ࡀ㣕⾜ࡢ࣮ࣝࣝ㸪㣕⾜ྍ⬟࡞✵ᇦ࡟
Management (SWIM) concept-oriented operationࡘ࠸࡚ㄆ㆑ࡍࡿࡼ࠺࡟࡞ࡗ࡚ࡁࡓࠋ↓ே⯟✵[1][2]. Its concept has been developed by Internationalᶵࡢ฼ά⏝ࡣ㸪㛵ಀ┬ᗇ㐃⤡఍㆟࡟࠾ࡅࡿᐁ
Civil Aviation Organization (ICAO) to illustrateẸ༠㆟఍࡟࠾࠸࡚㸪ᢏ⾡㛤Ⓨ࡜⎔ቃᩚഛ࡟㛵
information for flow management,
flight planning, andࡍࡿ࣮ࣟࢻ࣐ࢵࣉࡀ♧ࡉࢀ [1] 㸪ᑠᆺ↓ேᶵࡢ
trajectory management associated with Air Traffic฼⏝ࢆಁ㐍ࡋࡘࡘᏳ඲☜ಖࢆࡍࡿࡓࡵࡢไᗘ
Management (ATM) operational components. It willసࡾࡢ᳨ウࡀ㐍ࡵࡽࢀ࡚࠸ࡿࠋ᳨ウ࡟࠾࠸࡚be used by the ATM community as the basis for whichࡣ㸪ไᗘタィ࡟㛵ࡋ࡚ࡣ㸪฼⏝ಁ㐍࡜Ᏻ඲☜
ICAO Standards and Recommended Practicesಖࡢࣂࣛࣥࢫࢆ࡜ࡿࡇ࡜ࡀ㔜せ࡜ࡉࢀ࡚࠸ࡿ
[2](SARPs)will be developed in order to ensure that theࠋࡋ࠿ࡋ㸪ᨵṇ⯟✵ἲ࡟ࡼࡾ↓ே⯟✵ᶵ࡜
FF-ICE concept can be implemented globally [3].
⯟✵ᶵࡢ㣕⾜⠊ᅖࡀ࠶ࡿ⛬ᗘศ㞳ࡉࢀࡘࡘ࠶
FF-ICE implementation has been divided into twoࡿ୍᪉࡛㸪౛እ࡜࡞ࡿ㣕⾜ࡣከࡃᏑᅾࡋ㸪✵phases proposed by the ATM Requirements andᇦ฼⏝⪅ࡢᏳ඲ࢆ☜ಖࡍࡿࡓࡵ࡟ࡣ࠸ࡃࡘࡶ

plannedin the 2016-2018 timeframe to provide ࡞࠾㸪Ᏻ඲ࡀᦆ࡞ࢃࢀࡿ࠾ࡑࢀࡀ࡞࠸ࡶࡢ
recommendations
to enhance implementation࡜ࡋ࡚ᅜᅵ஺㏻┬௧࡛ᐃࡵࡿࡶࡢࡣ㸪⯟✵ἲ
guidance
material. The
results and observationsof this᪋⾜つ๎㸦௨ୗ㸪ࠕ᪋⾜つ๎ࠖ࡜ࡍࡿࠋ
㸧࡟ࡼ
project
and 200
Tabletop
exercises have been reported byࡾ㸪㔜㔞ࢢ࣒ࣛᮍ‶࡜ࡉࢀ࡚࠸ࡿࠋFAA
at ATMRPP meetings [5][6][7][8].
 㣕⾜ࡢ࣮ࣝࣝ࡟㛵ࡋ࡚ࡣ㸪➨132 ᮲㸦㣕⾜
ࡢ⚗Ṇ✵ᇦ㸧
㸪➨ 132In order to promotethe ᮲ࡢ
SWIM2㸦㣕⾜ࡢ᪉ἲ㸧construction and 㸪theཬࡧ➨ 132᮲ࡢ 3㸦ᤚ⣴㸪ᩆຓ➼ࡢࡓࡵࡢ≉FF-ICE
implementationin the Asia-Pacific region,౛㸧࡟ᐃࡵࡽࢀ࡚࠾ࡾ㸪㣕⾜⚗Ṇ✵ᇦࡢヲ⣽㸪Japan
Civil Aviation Bureau(JCAB) joined this୪ࡧ࡟㣕⾜⚗Ṇ✵ᇦ࡟࠾ࡅࡿ㣕⾜ࡢチྍཬࡧ
projectfrom January, 2017. As a technical supporter
᪉ἲࡢヲ⣽࡟㛵ࡋ࡚ࡣ㸪᪋⾜つ๎࡛ᐃࡵࡽࢀ
of
JCAB, Electronic Navigation Research Institute࡚࠸ࡿࠋᨵṇ⯟✵ἲ࡟࠾࠸࡚↓ே⯟✵ᶵࡀ㣕
(ENRI) developed a test system for validation and⾜ࡍࡿ✵ᇦཬࡧ㣕⾜ࡢ᪉ἲ࡟㛵ࡍࡿᴫせ࡟ࡘ
participated
Lab exercises of Validation 1 and࠸࡚ㄝ᫂ࡍࡿࠋ
Validation 2/3 in collaboration with FAA, NAV
2.1.1 㣕⾜ࡍࡿ✵ᇦ
CANADA, NEC, NTT Data, ANA and JAL. In this↓ே⯟✵ᶵࡀ㣕⾜ࡍࡿ࡟࠶ࡓࡾチྍࢆᚲせpaper, the development and analysis of Lab exercises࡜ࡍࡿ✵ᇦࡣ㸪ḟࡢ㏻ࡾ࡛࠶ࡿࠋ
related to the regional SWIM implementation are(a) ⯟✵ᶵࡢ⯟⾜ࡢᏳ඲࡟ᙳ㡪ࢆཬࡰࡍ࠾ࡑ
reported. Moreover, the problems and challenges forࢀࡢ࠶ࡿ✵ᇦ
constructing the FF-ICE operating environment to࣭✵ ➼ࡢ࿘㎶ࡢୖ✵ࡢ✵ᇦinclude interactions of the ATM stakeholders using࣭ᆅ⾲ཪࡣỈ㠃࠿ࡽ 150m ௨ୖࡢ㧗ࡉࡢ✵
data, ᇦsystems, and services through a SWIM
environment
are discussed.
(b) ேࡲࡓࡣᐙᒇࡢᐦ㞟ࡋ࡚࠸ࡿᆅᇦࡢୖ✵The
paper is structured as follows. In the next࣭ᅜໃㄪᰝࡢ⤖ᯝࢆཷࡅタᐃࡉࢀ࡚࠸ࡿே
section,the FF-ICE concept and the overview ofཱྀ㞟୰ᆅ༊ࡢୖ✵IIH&V are introduced. In section 3, the development

Performance Panel (ATMRPP). The first phase is FFࡢㄢ㢟ࡀ࠶ࡿࠋ
Planning (FF-ICE/1) that is focused on achieving
ICEᮏ✏࡛ࡣ㸪ࡇࢀࡽࡢㄢ㢟ࡢࡦ࡜ࡘ࡜⪃࠼ࡽ
the interoperability of ground-to-ground informationࢀࡿ㸪᫖௒ࢻ࣮ࣟࣥ࡜࿧ࡤࢀࡿࡼ࠺࡞ᑠᆺ↓ேᶵࡀ㣕⾜ࡍࡿ✵ᇦ࡛ࡢ⯟✵ᶵ㐠⯟࡟ࡘ࠸࡚
exchanges by using standard information exchange⪃ᐹࡍࡿࠋ✵
እࡢప㧗ᗘࢆ㣕⾜ࡍࡿ⯟✵ᶵ
models in the pre-departurephase of flight. The second࡜ᑠᆺ↓ேᶵࡢ㣕⾜࢚ࣜ࢔ࡀ➇ྜࡍࡿྍ⬟ᛶphase is FF-ICE Execution (FF-ICE/2) that willࡀ࠶ࡾ㸪ᑠᆺ↓ேᶵࡢ㣕⾜ᩘࡀቑຍࡍࢀࡤ᥋
support Trajectory Based Operation (TBO) through㏆ࡍࡿ☜⋡ࡶ㧗ࡃ࡞ࡿࠋ௒ᚋ฼ά⏝ࡀಁ㐍ࡉ
ground-to-ground and air-to-ground (A/G) SWIMࢀ㣕⾜㟂せࡀ㧗ࡲࡿ࡜ᛮࢃࢀࡿᑠᆺ↓ேᶵࡀ
exchanges in the post-departure phase of flight. These㣕⾜ࡍࡿ࢚ࣜ࢔ࡢᏳ඲☜ಖࡢࡓࡵ࡟ࡶ㸪᪩ᛴ
information exchanges will enable a common࡟ྲྀࡾ⤌ࡲ࡞ࡅࢀࡤ࡞ࡽ࡞࠸ㄢ㢟ࡢࡦ࡜ࡘ࡛
operational picture between aviation stakeholders in࠶ࡿࠋorder to support collaborative ATM and TBO.
2 ᨵṇ⯟✵ἲ࡟ࡼࡿチྍᢎㄆ࡟ࡘ࠸࡚
Therefore, ATM Service Providers (ASPs), Airspace ᨵṇ⯟✵ἲ࡟ࡼࡾ㸪↓ே⯟✵ᶵࡀᐃ⩏ࡉࢀ
Users (AUs), and other aviation stakeholders will need㣕⾜ࡢ࣮ࣝࣝࡀᩚ⌮ࡉࢀࡓࠋ⯟✵ἲ࡛ࡣ㸪↓to determine the operational processes, procedures,ே⯟✵ᶵࡢ㣕⾜ࡀ㸪᭷ே⯟✵ᶵࡢ㣕⾜㸪ேཬand automation changes required for FF-ICEࡧ≀௳➼࡟ᙳ㡪ࢆཬࡤࡉ࡞࠸ࡇ࡜ࢆ┠ⓗ࡟ᐃ
implementation [4].
ࡵࡽࢀ࡚࠸ࡿࠋ
However,with the different conditions, it is difficultᨵṇ⯟✵ἲࡢᴫせ
2.1
all ASPs to2 transformfrom the current operation tofor⯟✵ἲ➨᮲➨ 22 㡯࡟࠾࠸࡚↓ே⯟✵ᶵࡣ
the FF-ICE/1 based operation at the same time.
ḟࡢࡼ࠺࡟ᐃ⩏ࡉࢀ࡚࠸ࡿࠋ
Moreover, not all AUs will adopt the changes at the-1-71-

平成30年度（第18回）電子航法研究所研究発表会

平成30年度（第18回）電子航法研究所研究発表会

of local system for Validation 1 and Validation 2/3 Labacollaborativeenvironment

withextensiveࡍࡿ✵ᇦ࡟࠾ࡅࡿ⯟✵ᶵ㐠⯟࡟㛵ࡍࡿ⪃ᐹ
exercises and the lessons learned are presented andinformation content. The FF-ICE concept will provide

ࡀ᪋⾜ࡉࢀ
↓ே⯟✵ᶵ
⬟࡞✵ᇦ࡟
ࠋ↓ே⯟✵
࡟࠾ࡅࡿᐁ
ቃᩚഛ࡟㛵
ᆺ↓ேᶵࡢ
ࡓࡵࡢไᗘ
ウ࡟࠾࠸࡚
㐍࡜Ᏻ඲☜
ࡉࢀ࡚࠸ࡿ
ே⯟✵ᶵ࡜
ࡉࢀࡘࡘ࠶
Ꮡᅾࡋ㸪✵
ࡣ࠸ࡃࡘࡶ

ࡘ࡜⪃࠼ࡽ
࠺࡞ᑠᆺ↓
⯟࡟ࡘ࠸࡚
ࡍࡿ⯟✵ᶵ
ࡍࡿྍ⬟ᛶ
ຍࡍࢀࡤ᥋
⏝ࡀಁ㐍ࡉ
ᆺ↓ேᶵࡀ
࡟ࡶ㸪᪩ᛴ
ࡢࡦ࡜ࡘ࡛

ࡘ࠸࡚
ࡀᐃ⩏ࡉࢀ
ἲ࡛ࡣ㸪↓
㣕⾜㸪ேཬ
ࢆ┠ⓗ࡟ᐃ

ே⯟✵ᶵࡣ

analyzed. ⯟✵஺㏻⟶⌮㡿ᇦThe problems and challenges
to achievea globally harmonized process for planning andͤᖹᯘ༤Ꮚ㸪⹡㇂኱ᆅinteroperability is discussed in section 4, and the paper
providing consistent flight information [1].
┘ど㏻ಙ㡿ᇦ ἙᮧᬡᏊis concluded in section 5.
FF-ICE/1 is the first step towards achieving the FF-

ICE concept, and is primarily concerned with pre2. ࠗࡇࡢἲᚊ࡟࠾࠸࡚ࠕ↓ே⯟✵ᶵࠖ࡜ࡣ㸪⯟
FF-ICE CONCEPT AND IIH&V
departure data and processes in a mixed-mode✵ࡢ⏝࡟౪ࡍࡿࡇ࡜ࡀ࡛ࡁࡿ㣕⾜ᶵ㸪ᅇ㌿environment. This will involve the interoperability for
2.1 FF-ICE Concept⩼⯟✵ᶵ㸪⁥✵ᶵ㸪㣕⾜⯪ࡑࡢ௚ᨻ௧࡛ᐃ
flight plan coordination between partners that haveThe ࡵࡿᶵჾ࡛࠶ࡗ࡚ᵓ㐀ୖேࡀ஌ࡿࡇ࡜ࡀ࡛
present-day ICAO flight planning provisions
SWIM flight plan filing capabilities and partners thatwere developedon the basis of a manual, paper-based,ࡁ࡞࠸ࡶࡢࡢ࠺ࡕ㸪㐲㝸᧯సཪࡣ⮬ື᧯⦪are filing through existing systems.
point-to-point,
teletype communications system. A㸦ࣉࣟࢢ࣒ࣛ࡟ࡼࡾ⮬ືⓗ࡟᧯⦪ࢆ⾜࠺ࡇ
fundamental
changeis required to support the࡜ࢆ࠸࠺ࠋ㸧࡟ࡼࡾ㣕⾜ࡉࡏࡿࡇ࡜ࡀ࡛ࡁࡿ
2.2 Overview of IIH&V
implementationof the Global ATM Operationalࡶࡢ㸦ࡑࡢ㔜㔞ࡑࡢ௚ࡢ஦⏤ࢆ຺᱌ࡋ࡚ࡑ
As a main technical supporter of JCAB, ENRI isࡢ㣕⾜࡟ࡼࡾ⯟✵ᶵࡢ⯟⾜ࡢᏳ඲୪ࡧ࡟ᆅ
Conceptthat has greater data requirements [9]. These
collaborating with FAA and other internationalୖཬࡧỈୖࡢேཬࡧ≀௳ࡢᏳ඲ࡀᦆ࡞ࢃࢀ
include system-wide information sharing, providing
aviation participants on the IIH&V to validate FF-ICE
early ࡿ࠾ࡑࢀࡀ࡞࠸ࡶࡢ࡜ࡋ࡚ᅜᅵ஺㏻┬௧࡛intent data, management by trajectory,
concepts for potential implementation in the local
ᐃࡵࡿࡶࡢࢆ㝖ࡃࠋ㸧ࢆ࠸࠺ࠋ
coordinateddecision making,and high࠘automation
system, as well as the interoperability between the
support requiring machine readability andlocal system and international ANSPs components. It ࡞࠾㸪Ᏻ඲ࡀᦆ࡞ࢃࢀࡿ࠾ࡑࢀࡀ࡞࠸ࡶࡢ
unambiguous
information [10]. The limitations ofis expected that this project will align current and࡜ࡋ࡚ᅜᅵ஺㏻┬௧࡛ᐃࡵࡿࡶࡢࡣ㸪⯟✵ἲ
current
flight planning provisions and how the FF-ICE
future Collaborative Action for Renovation of Air᪋⾜つ๎㸦௨ୗ㸪ࠕ᪋⾜つ๎ࠖ࡜ࡍࡿࠋ㸧࡟ࡼ
concept addresses them are summarized in Table 1.
Traffic Systems (CARATS) activities with the ICAOࡾ㸪㔜㔞 200 ࢢ࣒ࣛᮍ‶࡜ࡉࢀ࡚࠸ࡿࠋ 㣕⾜ࡢ࣮ࣝࣝ࡟㛵ࡋ࡚ࡣ㸪➨᮲㸦㣕⾜ provisions to improve the accuracy and availability ofTable
1. Current Provisions and FF-ICE132
Conceptࡢ⚗Ṇ✵ᇦ㸧
㸪➨132 ᮲ࡢ 2㸦㣕⾜ࡢ᪉ἲ㸧㸪 flight information, and consistency of flight planning
Items
Current
Provisions
FF-ICE Concept
in different ATM environments and ANSP domains.
ཬࡧ➨ 132᮲ࡢ 3㸦ᤚ⣴㸪ᩆຓ➼ࡢࡓࡵࡢ≉Information
Multiple two-party
All relatedThis project consists of three Validation Exercises౛㸧࡟ᐃࡵࡽࢀ࡚࠾ࡾ㸪㣕⾜⚗Ṇ✵ᇦࡢヲ⣽㸪
sharingexchange
stakeholders୪ࡧ࡟㣕⾜⚗Ṇ✵ᇦ࡟࠾ࡅࡿ㣕⾜ࡢチྍཬࡧ consisting of several Tabletop and Lab exercises to
Advance
Short termLong term
validate key ICAO provisions [11].
᪉ἲࡢヲ⣽࡟㛵ࡋ࡚ࡣ㸪᪋⾜つ๎࡛ᐃࡵࡽࢀ
Notification
The goal of Validation 1 is to evaluate the viability࡚࠸ࡿࠋᨵṇ⯟✵ἲ࡟࠾࠸࡚↓ே⯟✵ᶵࡀ㣕
FlightGUFI based global⾜ࡍࡿ✵ᇦཬࡧ㣕⾜ࡢ᪉ἲ࡟㛵ࡍࡿᴫせ࡟ࡘ
Local managementof the implementation of FF-ICE/1 in the 2020
Information
management࠸࡚ㄝ᫂ࡍࡿࠋ
timeframe. That includes Flight Plan Submission,
InformationPeer-to-peer
SWIM based
2.1.1 㣕⾜ࡍࡿ✵ᇦMonitoring, and Distribution which targets the predistribution
communications
interoperability↓ே⯟✵ᶵࡀ㣕⾜ࡍࡿ࡟࠶ࡓࡾチྍࢆᚲせ departure coordination of flight plans between ASPs in
Information
Multi-layered࡜ࡍࡿ✵ᇦࡣ㸪ḟࡢ㏻ࡾ࡛࠶ࡿࠋ
a mixed-mode environment. Validation 2 and 3
Single policy
security
governance(a) ⯟✵ᶵࡢ⯟⾜ࡢᏳ඲࡟ᙳ㡪ࢆཬࡰࡍ࠾ࡑ
expanded trajectory negotiations to the post-departure
Information
Local definitions;Standard models;ࢀࡢ࠶ࡿ✵ᇦ
portion concerning with the A/G SWIM integration byset
data lengths
Flexible format
࣭✵ Fixed➼ࡢ࿘㎶ࡢୖ✵ࡢ✵ᇦapplying Electronic Flight Bag (EFB) with single or࣭ᆅ⾲ཪࡣỈ㠃࠿ࡽ
150m
௨ୖࡢ㧗ࡉࡢ✵Derivable
Independence;
Interaction;
bi-directional data link communications [12].
informationᇦ Inconsistency
Consistency
The Tabletop Exercises focus on operational, policy,(b) ேࡲࡓࡣᐙᒇࡢᐦ㞟ࡋ࡚࠸ࡿᆅᇦࡢୖ✵and procedure questions. The development of the
In orderto achieve a safe, secure, efficient and࣭ᅜໃㄪᰝࡢ⤖ᯝࢆཷࡅタᐃࡉࢀ࡚࠸ࡿே
system capability in Lab Exercises is determinedཱྀ㞟୰ᆅ༊ࡢୖ✵environmentally
sustainable air navigation system ataccording to these discussions. Tabletop Exercises areglobal, regional and local levels, future ATM requires

-1-

-72-

平成30年度（第18回）電子航法研究所研究発表会

performed for all vignettes. Based on defined down㸯㸬ᑠᆺ↓ேᶵࡀ㣕⾜ࡍࡿ✵ᇦ࡟࠾ࡅࡿ⯟✵ᶵ㐠⯟࡟㛵ࡍࡿ⪃ᐹ
selection
criteria, some scenarios of Tabletop
Exercises are selected and conducted as Lab Exercises.

⯟✵஺㏻⟶⌮㡿ᇦ ͤᖹᯘ༤Ꮚ㸪⹡㇂኱ᆅResults from these validation exercises will be used to┘ど㏻ಙ㡿ᇦ ἙᮧᬡᏊinform the development of any future implementation
guidance, ASP procedures, AU procedures, and future1 ࡣࡌࡵ࡟
revisions of ICAO Provisions (Figure 1). In the next ᖹᡂ 27 ᖺ 12 ᭶࡟⯟✵ἲࡢᨵṇࡀ᪋⾜ࡉࢀsection, additional details on Lab Exercises of࡚࠿ࡽ 2 ᖺ㏆ࡃࡀ⤒㐣ࡋ㸪ከࡃࡢ↓ே⯟✵ᶵ
Validation 1 and 2/3 are presented.
࣮ࣘࢨ࣮ࡀ㣕⾜ࡢ࣮ࣝࣝ㸪㣕⾜ྍ⬟࡞✵ᇦ࡟ࡘ࠸࡚ㄆ㆑ࡍࡿࡼ࠺࡟࡞ࡗ࡚ࡁࡓࠋ↓ே⯟✵
Validation Objectivesᶵࡢ฼ά⏝ࡣ㸪㛵ಀ┬ᗇ㐃⤡఍㆟࡟࠾ࡅࡿᐁ
Provisions
Scenarios / Vignettes
StakeholdersẸ༠㆟఍࡟࠾࠸࡚㸪ᢏ⾡㛤Ⓨ࡜⎔ቃᩚഛ࡟㛵ࡍࡿ࣮ࣟࢻ࣐ࢵࣉࡀ♧ࡉࢀ [1] 㸪ᑠᆺ↓ேᶵࡢ
Down Selection
Operational฼⏝ࢆಁ㐍ࡋࡘࡘᏳ඲☜ಖࢆࡍࡿࡓࡵࡢไᗘ
Criteria
Performance Questions
సࡾࡢ᳨ウࡀ㐍ࡵࡽࢀ࡚࠸ࡿࠋ᳨ウ࡟࠾࠸࡚ࡣ㸪ไᗘタィ࡟㛵ࡋ࡚ࡣ㸪฼⏝ಁ㐍࡜Ᏻ඲☜ಖࡢࣂࣛࣥࢫࢆ࡜ࡿࡇ࡜ࡀ㔜せ࡜ࡉࢀ࡚࠸ࡿ
Conduct Lab
Conduct[2]
Exercise(s)Tabletopsࠋࡋ࠿ࡋ㸪ᨵṇ⯟✵ἲ࡟ࡼࡾ↓ே⯟✵ᶵ࡜⯟✵ᶵࡢ㣕⾜⠊ᅖࡀ࠶ࡿ⛬ᗘศ㞳ࡉࢀࡘࡘ࠶
ࡿ୍᪉࡛㸪౛እ࡜࡞ࡿ㣕⾜ࡣከࡃᏑᅾࡋ㸪✵
Performance Measures Results / Stakeholder Outbrief /Operational Valueᇦ฼⏝⪅ࡢᏳ඲ࢆ☜ಖࡍࡿࡓࡵ࡟ࡣ࠸ࡃࡘࡶ
ࡢㄢ㢟ࡀ࠶ࡿࠋ ᮏ✏࡛ࡣ㸪ࡇࢀࡽࡢㄢ㢟ࡢࡦ࡜ࡘ࡜⪃࠼ࡽ
ATMRPP,
Final Report
Standards WG Reportsࢀࡿ㸪᫖௒ࢻ࣮ࣟࣥ࡜࿧ࡤࢀࡿࡼ࠺࡞ᑠᆺ↓ேᶵࡀ㣕⾜ࡍࡿ✵ᇦ࡛ࡢ⯟✵ᶵ㐠⯟࡟ࡘ࠸࡚
Figure 1: Validation Exercise Approach⪃ᐹࡍࡿࠋ✵ እࡢప㧗ᗘࢆ㣕⾜ࡍࡿ⯟✵ᶵ
3. LAB EXERCISES࡜ᑠᆺ↓ேᶵࡢ㣕⾜࢚ࣜ࢔ࡀ➇ྜࡍࡿྍ⬟ᛶࠗࡇࡢἲᚊ࡟࠾࠸࡚ࠕ↓ே⯟✵ᶵࠖ࡜ࡣ㸪⯟✵ࡢ⏝࡟౪ࡍࡿࡇ࡜ࡀ࡛ࡁࡿ㣕⾜ᶵ㸪ᅇ㌿⩼⯟✵ᶵ㸪⁥✵ᶵ㸪㣕⾜⯪ࡑࡢ௚ᨻ௧࡛ᐃ
ࡵࡿᶵჾ࡛࠶ࡗ࡚ᵓ㐀ୖேࡀ஌ࡿࡇ࡜ࡀ࡛
ࡁ࡞࠸ࡶࡢࡢ࠺ࡕ㸪㐲㝸᧯సཪࡣ⮬ື᧯⦪㸦ࣉࣟࢢ࣒ࣛ࡟ࡼࡾ⮬ືⓗ࡟᧯⦪ࢆ⾜࠺ࡇ࡜ࢆ࠸࠺ࠋ㸧࡟ࡼࡾ㣕⾜ࡉࡏࡿࡇ࡜ࡀ࡛ࡁࡿ
Figure 2: System
Architecture for Validation 1ࡶࡢ㸦ࡑࡢ㔜㔞ࡑࡢ௚ࡢ஦⏤ࢆ຺᱌ࡋ࡚ࡑ
ࡢ㣕⾜࡟ࡼࡾ⯟✵ᶵࡢ⯟⾜ࡢᏳ඲୪ࡧ࡟ᆅThe
GEMS Providers are charged to enforce the useୖཬࡧỈୖࡢேཬࡧ≀௳ࡢᏳ඲ࡀᦆ࡞ࢃࢀ
of the standardized aeronautical, flight and weatherࡿ࠾ࡑࢀࡀ࡞࠸ࡶࡢ࡜ࡋ࡚ᅜᅵ஺㏻┬௧࡛
exchange models (AIXM, FIXM and iWXXM) withᐃࡵࡿࡶࡢࢆ㝖ࡃࠋ㸧ࢆ࠸࠺ࠋ࠘
the updated versions for each of their SWIM nodes toensure the interoperability of the exchanged ࡞࠾㸪Ᏻ඲ࡀᦆ࡞ࢃࢀࡿ࠾ࡑࢀࡀ࡞࠸ࡶࡢ
information [13]. The communication between SFF
࡜ࡋ࡚ᅜᅵ஺㏻┬௧࡛ᐃࡵࡿࡶࡢࡣ㸪⯟✵ἲ
and NEC is based on Secure Sockets Layer (SSL). And᪋⾜つ๎㸦௨ୗ㸪ࠕ᪋⾜つ๎ࠖ࡜ࡍࡿࠋ㸧࡟ࡼ
the SSL is also used for communication between NECࡾ㸪㔜㔞 200 ࢢ࣒ࣛᮍ‶࡜ࡉࢀ࡚࠸ࡿࠋ
andregional users. The communicationfor 㣕⾜ࡢ࣮ࣝࣝ࡟㛵ࡋ࡚ࡣ㸪➨132standard᮲㸦㣕⾜
Publish/Subscribe
Advanced Messaging
ࡢ⚗Ṇ✵ᇦ㸧㸪➨messaging
132 ᮲ࡢis 2㸦㣕⾜ࡢ᪉ἲ㸧㸪Queuing
Protocol(AMQP).
ཬࡧ➨ 132 ᮲ࡢ 3㸦ᤚ⣴㸪ᩆຓ➼ࡢࡓࡵࡢ≉(2)
Validation౛㸧࡟ᐃࡵࡽࢀ࡚࠾ࡾ㸪㣕⾜⚗Ṇ✵ᇦࡢヲ⣽㸪
Accordingtothedefinitionin the ICAO FF-ICE/1
୪ࡧ࡟㣕⾜⚗Ṇ✵ᇦ࡟࠾ࡅࡿ㣕⾜ࡢチྍཬࡧ
Provisions,the following message types in the FIXM
᪉ἲࡢヲ⣽࡟㛵ࡋ࡚ࡣ㸪᪋⾜つ๎࡛ᐃࡵࡽࢀ
4.0
format are validated for the pre-departure phase of࡚࠸ࡿࠋᨵṇ⯟✵ἲ࡟࠾࠸࡚↓ே⯟✵ᶵࡀ㣕ࡀ࠶ࡾ㸪ᑠᆺ↓ேᶵࡢ㣕⾜ᩘࡀቑຍࡍࢀࡤ᥋
3.1 Validation 1 Lab Exercise㏆ࡍࡿ☜⋡ࡶ㧗ࡃ࡞ࡿࠋ௒ᚋ฼ά⏝ࡀಁ㐍ࡉ(1) System Architectureࢀ㣕⾜㟂せࡀ㧗ࡲࡿ࡜ᛮࢃࢀࡿᑠᆺ↓ேᶵࡀIn the Lab exercise of Validation 1, there are two㣕⾜ࡍࡿ࢚ࣜ࢔ࡢᏳ඲☜ಖࡢࡓࡵ࡟ࡶ㸪᪩ᛴ
Global Enterprise Messaging Service (GEMS)࡟ྲྀࡾ⤌ࡲ࡞ࡅࢀࡤ࡞ࡽ࡞࠸ㄢ㢟ࡢࡦ࡜ࡘ࡛
providers that facilitate data sharing between a variety࠶ࡿࠋof ᨵṇ⯟✵ἲ࡟ࡼࡿチྍᢎㄆ࡟ࡘ࠸࡚
partners and applications. The mixed-mode
2
that includes participation by both FFenvironmentᨵṇ⯟✵ἲ࡟ࡼࡾ㸪↓ே⯟✵ᶵࡀᐃ⩏ࡉࢀ
ICE/1 capable and FF-ICE/1 non-capable ASPs is㣕⾜ࡢ࣮ࣝࣝࡀᩚ⌮ࡉࢀࡓࠋ⯟✵ἲ࡛ࡣ㸪↓flight.
There are two phases in the FF-ICE/1,
⾜ࡍࡿ✵ᇦཬࡧ㣕⾜ࡢ᪉ἲ࡟㛵ࡍࡿᴫせ࡟ࡘ࠸࡚ㄝ᫂ࡍࡿࠋ
Preliminary
phase and Filed phase. In each phase,㣕⾜ࡍࡿ✵ᇦ
2.1.1shouldeASPs
reply to the eAU regarding operational↓ே⯟✵ᶵࡀ㣕⾜ࡍࡿ࡟࠶ࡓࡾチྍࢆᚲせacceptabilityof their flight plans.
࡜ࡍࡿ✵ᇦࡣ㸪ḟࡢ㏻ࡾ࡛࠶ࡿࠋ
The validation of flight information exchange(a) ⯟✵ᶵࡢ⯟⾜ࡢᏳ඲࡟ᙳ㡪ࢆཬࡰࡍ࠾ࡑ
model(FIXM 4.0) implementation is an essentialࢀࡢ࠶ࡿ✵ᇦ
component of the Validation 1 Lab exercise. The goalof ࣭✵
the Lab➼ࡢ࿘㎶ࡢୖ✵ࡢ✵ᇦ
exercise is not only to validate FF-ICE/1࣭ᆅ⾲ཪࡣỈ㠃࠿ࡽ 150m ௨ୖࡢ㧗ࡉࡢ✵
messages but also evaluate all states and status options
ᇦ
of the messages. The FF-ICE/1 messages based(b) ேࡲࡓࡣᐙᒇࡢᐦ㞟ࡋ࡚࠸ࡿᆅᇦࡢୖ✵operations of JAL in coordination with FAA, NAV࣭ᅜໃㄪᰝࡢ⤖ᯝࢆཷࡅタᐃࡉࢀ࡚࠸ࡿே
CANADA and JCAB for the KJFK-RJAA scenario areཱྀ㞟୰ᆅ༊ࡢୖ✵shown in Figure 3.

considered. The FF-ICE/1 capable ASP and AU areே⯟✵ᶵࡢ㣕⾜ࡀ㸪᭷ே⯟✵ᶵࡢ㣕⾜㸪ேཬreferred to as eASP and eAU (enabled ASP and AU).
ࡧ≀௳➼࡟ᙳ㡪ࢆཬࡤࡉ࡞࠸ࡇ࡜ࢆ┠ⓗ࡟ᐃࡵࡽࢀ࡚࠸ࡿࠋAs shown in Figure 2, the FAA, NAV CANADA and2.1
legacyᨵṇ⯟✵ἲࡢᴫせ
ASPs connect to SkyFusion Frontier (SFF),
which⯟✵ἲ➨
2 ᮲➨ 22by㡯࡟࠾࠸࡚↓ே⯟✵ᶵࡣ
is supported
Harris Corporation. NECḟࡢࡼ࠺࡟ᐃ⩏ࡉࢀ࡚࠸ࡿࠋ
provides the GEMS connections (SBN) to local eASPs
and eAUs (JCAB, JAL, ANA).

-1-73-

平成30年度（第18回）電子航法研究所研究発表会

平成30年度（第18回）電子航法研究所研究発表会ࡍࡿ✵ᇦ࡟࠾ࡅࡿ⯟✵ᶵ㐠⯟࡟㛵ࡍࡿ⪃ᐹ

ࡀ᪋⾜ࡉࢀ
↓ே⯟✵ᶵ
⬟࡞✵ᇦ࡟
ࠋ↓ே⯟✵
࡟࠾ࡅࡿᐁ
ቃᩚഛ࡟㛵
ᆺ↓ேᶵࡢ
ࡓࡵࡢไᗘ
ウ࡟࠾࠸࡚
㐍࡜Ᏻ඲☜
ࡉࢀ࡚࠸ࡿ
ே⯟✵ᶵ࡜
ࡉࢀࡘࡘ࠶
Ꮡᅾࡋ㸪✵
ࡣ࠸ࡃࡘࡶ

ࡘ࡜⪃࠼ࡽ
࠺࡞ᑠᆺ↓
⯟࡟ࡘ࠸࡚
ࡍࡿ⯟✵ᶵ
ࡍࡿྍ⬟ᛶ
ຍࡍࢀࡤ᥋
⏝ࡀಁ㐍ࡉ
ᆺ↓ேᶵࡀ
࡟ࡶ㸪᪩ᛴ
ࡢࡦ࡜ࡘ࡛

ࡘ࠸࡚
ࡀᐃ⩏ࡉࢀ
ἲ࡛ࡣ㸪↓
㣕⾜㸪ேཬ
ࢆ┠ⓗ࡟ᐃ

ே⯟✵ᶵࡣ

⯟✵஺㏻⟶⌮㡿ᇦ ͤᖹᯘ༤Ꮚ㸪⹡㇂኱ᆅ┘ど㏻ಙ㡿ᇦ ἙᮧᬡᏊࠗࡇࡢἲᚊ࡟࠾࠸࡚ࠕ↓ே⯟✵ᶵࠖ࡜ࡣ㸪⯟✵ࡢ⏝࡟౪ࡍࡿࡇ࡜ࡀ࡛ࡁࡿ㣕⾜ᶵ㸪ᅇ㌿⩼⯟✵ᶵ㸪⁥✵ᶵ㸪㣕⾜⯪ࡑࡢ௚ᨻ௧࡛ᐃ
ࡵࡿᶵჾ࡛࠶ࡗ࡚ᵓ㐀ୖேࡀ஌ࡿࡇ࡜ࡀ࡛
ࡁ࡞࠸ࡶࡢࡢ࠺ࡕ㸪㐲㝸᧯సཪࡣ⮬ື᧯⦪㸦ࣉࣟࢢ࣒ࣛ࡟ࡼࡾ⮬ືⓗ࡟᧯⦪ࢆ⾜࠺ࡇ࡜ࢆ࠸࠺ࠋ㸧࡟ࡼࡾ㣕⾜ࡉࡏࡿࡇ࡜ࡀ࡛ࡁࡿ
ࡶࡢ㸦ࡑࡢ㔜㔞ࡑࡢ௚ࡢ஦⏤ࢆ຺᱌ࡋ࡚ࡑ
ࡢ㣕⾜࡟ࡼࡾ⯟✵ᶵࡢ⯟⾜ࡢᏳ඲୪ࡧ࡟ᆅ
ୖཬࡧỈୖࡢேཬࡧ≀௳ࡢᏳ඲ࡀᦆ࡞ࢃࢀ
ࡿ࠾ࡑࢀࡀ࡞࠸ࡶࡢ࡜ࡋ࡚ᅜᅵ஺㏻┬௧࡛ᐃࡵࡿࡶࡢࢆ㝖ࡃࠋ㸧ࢆ࠸࠺ࠋ࠘ ࡞࠾㸪Ᏻ඲ࡀᦆ࡞ࢃࢀࡿ࠾ࡑࢀࡀ࡞࠸ࡶࡢ
Figure 3: JAL Simulator࡜ࡋ࡚ᅜᅵ஺㏻┬௧࡛ᐃࡵࡿࡶࡢࡣ㸪⯟✵ἲ᪋⾜つ๎㸦௨ୗ㸪㸧࡟ࡼ (DMS) and the EFB simulator. And to increase
Table 2.ࠕ᪋⾜つ๎ࠖ࡜ࡍࡿࠋ
Message Types
ࡾ㸪㔜㔞
Message200
Typesࢢ࣒ࣛᮍ‶࡜ࡉࢀ࡚࠸ࡿࠋ
Descriptions
efficiency by removing extra process for information 㣕⾜ࡢ࣮ࣝࣝ࡟㛵ࡋ࡚ࡣ㸪➨132
᮲㸦㣕⾜
exchanges, all SWIM-enabled applications are
E_PFP
Preliminary Flight Planࡢ⚗Ṇ✵ᇦ㸧㸪➨ 132 ᮲ࡢ 2㸦㣕⾜ࡢ᪉ἲ㸧㸪connected to the ENRI Local EMS that is directly
E_FPL
Filed Flight Planཬࡧ➨ 132 ᮲ࡢ 3㸦ᤚ⣴㸪ᩆຓ➼ࡢࡓࡵࡢ≉connected to the SBN.
SUB_RESP
Submission Response౛㸧࡟ᐃࡵࡽࢀ࡚࠾ࡾ㸪㣕⾜⚗Ṇ✵ᇦࡢヲ⣽㸪
FIL_STATUS
Filing Status୪ࡧ࡟㣕⾜⚗Ṇ✵ᇦ࡟࠾ࡅࡿ㣕⾜ࡢチྍཬࡧ
PLAN_STATUS
Planning Status
᪉ἲࡢヲ⣽࡟㛵ࡋ࡚ࡣ㸪᪋⾜つ๎࡛ᐃࡵࡽࢀ
E_FPL_UPDATE Flight Plan Update࡚࠸ࡿࠋᨵṇ⯟✵ἲ࡟࠾࠸࡚↓ே⯟✵ᶵࡀ㣕
E_ARRIVAL
Arrival⾜ࡍࡿ✵ᇦཬࡧ㣕⾜ࡢ᪉ἲ࡟㛵ࡍࡿᴫせ࡟ࡘ
E_DEPARTURE
Departure࠸࡚ㄝ᫂ࡍࡿࠋ
E_CANCEL
Cancel㣕⾜ࡍࡿ✵ᇦ
2.1.1
↓ே⯟✵ᶵࡀ㣕⾜ࡍࡿ࡟࠶ࡓࡾチྍࢆᚲせE_TRIAL_REQ
Trial Request࡜ࡍࡿ✵ᇦࡣ㸪ḟࡢ㏻ࡾ࡛࠶ࡿࠋ
E_TRIAL_RESP
Trial Response(a) E_INFO_REQ⯟✵ᶵࡢ⯟⾜ࡢᏳ඲࡟ᙳ㡪ࢆཬࡰࡍ࠾ࡑ
Request Flight Informationࢀࡢ࠶ࡿ✵ᇦ
E_INFO_RESP
Flight Information Response࣭✵ ➼ࡢ࿘㎶ࡢୖ✵ࡢ✵ᇦ
Figure 4: System Architecture for Validation 2/3࣭ᆅ⾲ཪࡣỈ㠃࠿ࡽ 150m ௨ୖࡢ㧗ࡉࡢ✵
3.2. Validation
2/3 Lab Exercise
ᇦ
The DMS is an access point for achieving Aircraftேࡲࡓࡣᐙᒇࡢᐦ㞟ࡋ࡚࠸ࡿᆅᇦࡢୖ✵(1)(b)
SystemArchitecture
Access to SWIM (AAtS) developed to store, manage,
࣭ᅜໃㄪᰝࡢ⤖ᯝࢆཷࡅタᐃࡉࢀ࡚࠸ࡿேAs shown
in Figure 4, the main differences between
filter, and deliver ground data and air data to relatedཱྀ㞟୰ᆅ༊ࡢୖ✵the test system
of Validation 2/3 and Validation 1
users. The EFB simulator was developed to subscribe
include the addition of the Data Management Service

-1-

-74-

平成30年度（第18回）電子航法研究所研究発表会㸯㸬ᑠᆺ↓ேᶵࡀ㣕⾜ࡍࡿ✵ᇦ࡟࠾ࡅࡿ⯟✵ᶵ㐠⯟࡟㛵ࡍࡿ⪃ᐹ⯟✵஺㏻⟶⌮㡿ᇦ ͤᖹᯘ༤Ꮚ㸪⹡㇂኱ᆅ┘ど㏻ಙ㡿ᇦ ἙᮧᬡᏊ1 ࡣࡌࡵ࡟
ࠗࡇࡢἲᚊ࡟࠾࠸࡚ࠕ↓ே⯟✵ᶵࠖ࡜ࡣ㸪⯟ ᖹᡂ 27 ᖺ 12 ᭶࡟⯟✵ἲࡢᨵṇࡀ᪋⾜ࡉࢀ✵ࡢ⏝࡟౪ࡍࡿࡇ࡜ࡀ࡛ࡁࡿ㣕⾜ᶵ㸪ᅇ㌿࡚࠿ࡽ 2 ᖺ㏆ࡃࡀ⤒㐣ࡋ㸪ከࡃࡢ↓ே⯟✵ᶵ⩼⯟✵ᶵ㸪⁥✵ᶵ㸪㣕⾜⯪ࡑࡢ௚ᨻ௧࡛ᐃ
࣮ࣘࢨ࣮ࡀ㣕⾜ࡢ࣮ࣝࣝ㸪㣕⾜ྍ⬟࡞✵ᇦ࡟ࡵࡿᶵჾ࡛࠶ࡗ࡚ᵓ㐀ୖேࡀ஌ࡿࡇ࡜ࡀ࡛
ࡘ࠸࡚ㄆ㆑ࡍࡿࡼ࠺࡟࡞ࡗ࡚ࡁࡓࠋ↓ே⯟✵ࡁ࡞࠸ࡶࡢࡢ࠺ࡕ㸪㐲㝸᧯సཪࡣ⮬ື᧯⦪ᶵࡢ฼ά⏝ࡣ㸪㛵ಀ┬ᗇ㐃⤡఍㆟࡟࠾ࡅࡿᐁ
㸦ࣉࣟࢢ࣒ࣛ࡟ࡼࡾ⮬ືⓗ࡟᧯⦪ࢆ⾜࠺ࡇẸ༠㆟఍࡟࠾࠸࡚㸪ᢏ⾡㛤Ⓨ࡜⎔ቃᩚഛ࡟㛵࡜ࢆ࠸࠺ࠋ㸧࡟ࡼࡾ㣕⾜ࡉࡏࡿࡇ࡜ࡀ࡛ࡁࡿ
[1]ࡍࡿ࣮ࣟࢻ࣐ࢵࣉࡀ♧ࡉࢀ 㸪ᑠᆺ↓ேᶵࡢࡶࡢ㸦ࡑࡢ㔜㔞ࡑࡢ௚ࡢ஦⏤ࢆ຺᱌ࡋ࡚ࡑ
฼⏝ࢆಁ㐍ࡋࡘࡘᏳ඲☜ಖࢆࡍࡿࡓࡵࡢไᗘ
ࡢ㣕⾜࡟ࡼࡾ⯟✵ᶵࡢ⯟⾜ࡢᏳ඲୪ࡧ࡟ᆅ
సࡾࡢ᳨ウࡀ㐍ࡵࡽࢀ࡚࠸ࡿࠋ᳨ウ࡟࠾࠸࡚ୖཬࡧỈୖࡢேཬࡧ≀௳ࡢᏳ඲ࡀᦆ࡞ࢃࢀ
ࡣ㸪ไᗘタィ࡟㛵ࡋ࡚ࡣ㸪฼⏝ಁ㐍࡜Ᏻ඲☜ࡿ࠾ࡑࢀࡀ࡞࠸ࡶࡢ࡜ࡋ࡚ᅜᅵ஺㏻┬௧࡛ಖࡢࣂࣛࣥࢫࢆ࡜ࡿࡇ࡜ࡀ㔜せ࡜ࡉࢀ࡚࠸ࡿ
ᐃࡵࡿࡶࡢࢆ㝖ࡃࠋ㸧ࢆ࠸࠺ࠋ࠘
Figure 5: EFB Simulator for
Validation 2/3[2]ࠋࡋ࠿ࡋ㸪ᨵṇ⯟✵ἲ࡟ࡼࡾ↓ே⯟✵ᶵ࡜⯟✵ᶵࡢ㣕⾜⠊ᅖࡀ࠶ࡿ⛬ᗘศ㞳ࡉࢀࡘࡘ࠶ ࡞࠾㸪Ᏻ඲ࡀᦆ࡞ࢃࢀࡿ࠾ࡑࢀࡀ࡞࠸ࡶࡢ
related FIXM, AIXM and iWXXM messages for a
executionphase to make distinction between preࡿ୍᪉࡛㸪౛እ࡜࡞ࡿ㣕⾜ࡣከࡃᏑᅾࡋ㸪✵࡜ࡋ࡚ᅜᅵ஺㏻┬௧࡛ᐃࡵࡿࡶࡢࡣ㸪⯟✵ἲcertain aircraft; show related information anddeparture and post-departure change requests. Unlikeᇦ฼⏝⪅ࡢᏳ඲ࢆ☜ಖࡍࡿࡓࡵ࡟ࡣ࠸ࡃࡘࡶ
᪋⾜つ๎㸦௨ୗ㸪ࠕ᪋⾜つ๎ࠖ࡜ࡍࡿࠋ
㸧࡟ࡼ
documents on the map; generate landing reportthepre-departure FlightPlans and Flight Plan Updates,ࡢㄢ㢟ࡀ࠶ࡿࠋ
ࡾ㸪㔜㔞 200 ࢢ࣒ࣛᮍ‶࡜ࡉࢀ࡚࠸ࡿࠋ
according to the on-board and ground information andthe Update Request does not include the flight plan ᮏ✏࡛ࡣ㸪ࡇࢀࡽࡢㄢ㢟ࡢࡦ࡜ࡘ࡜⪃࠼ࡽ 㣕⾜ࡢ࣮ࣝࣝ࡟㛵ࡋ࡚ࡣ㸪➨ 132 ᮲㸦㣕⾜submit it to the DMS; request NOTAM, METAR andversion. A flight plan version is not included postࢀࡿ㸪᫖௒ࢻ࣮ࣟࣥ࡜࿧ࡤࢀࡿࡼ࠺࡞ᑠᆺ↓ࡢ⚗Ṇ✵ᇦ㸧㸪➨ 132 ᮲ࡢ 2㸦㣕⾜ࡢ᪉ἲ㸧㸪
TAF information from the ground SWIM services.
departure because the controller must take action, andேᶵࡀ㣕⾜ࡍࡿ✵ᇦ࡛ࡢ⯟✵ᶵ㐠⯟࡟ࡘ࠸࡚ཬࡧ➨ 132 ᮲ࡢ 3㸦ᤚ⣴㸪ᩆຓ➼ࡢࡓࡵࡢ≉(2) Validation
could also initiate a modification without a request⪃ᐹࡍࡿࠋ✵ እࡢప㧗ᗘࢆ㣕⾜ࡍࡿ⯟✵ᶵ౛㸧࡟ᐃࡵࡽࢀ࡚࠾ࡾ㸪㣕⾜⚗Ṇ✵ᇦࡢヲ⣽㸪
To continue with the scenario proposed infrom the AU, and therefore versioning number would࡜ᑠᆺ↓ேᶵࡢ㣕⾜࢚ࣜ࢔ࡀ➇ྜࡍࡿྍ⬟ᛶ୪ࡧ࡟㣕⾜⚗Ṇ✵ᇦ࡟࠾ࡅࡿ㣕⾜ࡢチྍཬࡧ
Validation 1, the JAL5 from KJFK to RJAA uses EFB
get out of order.
ࡀ࠶ࡾ㸪ᑠᆺ↓ேᶵࡢ㣕⾜ᩘࡀቑຍࡍࢀࡤ᥋᪉ἲࡢヲ⣽࡟㛵ࡋ࡚ࡣ㸪᪋⾜つ๎࡛ᐃࡵࡽࢀ
simulator for post-departure negotiation to achieve㏆ࡍࡿ☜⋡ࡶ㧗ࡃ࡞ࡿࠋ௒ᚋ฼ά⏝ࡀಁ㐍ࡉ࡚࠸ࡿࠋᨵṇ⯟✵ἲ࡟࠾࠸࡚↓ே⯟✵ᶵࡀ㣕
3.3.
Analysis
A/G
SWIM
integration.
Beforeenteringtheࢀ㣕⾜㟂せࡀ㧗ࡲࡿ࡜ᛮࢃࢀࡿᑠᆺ↓ேᶵࡀ⾜ࡍࡿ✵ᇦཬࡧ㣕⾜ࡢ᪉ἲ࡟㛵ࡍࡿᴫせ࡟ࡘ
In the FF-ICE/1 messages, there are two parts. One
FUKUOKA FIR, a digital NOTAM was received on㣕⾜ࡍࡿ࢚ࣜ࢔ࡢᏳ඲☜ಖࡢࡓࡵ࡟ࡶ㸪᪩ᛴ࠸࡚ㄝ᫂ࡍࡿࠋ
is message information part that includes contact
the EFB that the primary runway at the RJAA has been࡟ྲྀࡾ⤌ࡲ࡞ࡅࢀࡤ࡞ࡽ࡞࠸ㄢ㢟ࡢࡦ࡜ࡘ࡛
2.1.1 㣕⾜ࡍࡿ✵ᇦinformation,
flight plan version, and referenced
closeddue
toadisabled
aircraft.
↓ே⯟✵ᶵࡀ㣕⾜ࡍࡿ࡟࠶ࡓࡾチྍࢆᚲせ࠶ࡿࠋconstraints. The other is flight information part, suchshown in Figure 5, according to the latest࡜ࡍࡿ✵ᇦࡣ㸪ḟࡢ㏻ࡾ࡛࠶ࡿࠋ
2Asᨵṇ⯟✵ἲ࡟ࡼࡿチྍᢎㄆ࡟ࡘ࠸࡚
as aircraft information, 4D trajectory, and GUFI.
weather
information
for
RJAA
receivedvia
A/G ᨵṇ⯟✵ἲ࡟ࡼࡾ㸪↓ே⯟✵ᶵࡀᐃ⩏ࡉࢀ(a) ⯟✵ᶵࡢ⯟⾜ࡢᏳ඲࡟ᙳ㡪ࢆཬࡰࡍ࠾ࡑ
A key enabler to sharing flight data internationally
SWIM and the on-board data of aircraft, the EFB㣕⾜ࡢ࣮ࣝࣝࡀᩚ⌮ࡉࢀࡓࠋ⯟✵ἲ࡛ࡣ㸪↓ࢀࡢ࠶ࡿ✵ᇦ
is having the ability to unambiguously identify eachே⯟✵ᶵࡢ㣕⾜ࡀ㸪᭷ே⯟✵ᶵࡢ㣕⾜㸪ேཬ࣭✵ ➼ࡢ࿘㎶ࡢୖ✵ࡢ✵ᇦgenerated a landing report and identified that diverting
flight. This is accomplished by having a GUFIࡧ≀௳➼࡟ᙳ㡪ࢆཬࡤࡉ࡞࠸ࡇ࡜ࢆ┠ⓗ࡟ᐃ࣭ᆅ⾲ཪࡣỈ㠃࠿ࡽ 150m ௨ୖࡢ㧗ࡉࡢ✵
to RJTT is necessary due to a runway closure at RJAA.
assigned to each unique flight. A unique flight isࡵࡽࢀ࡚࠸ࡿࠋ
ᇦ
Using Trial Request and Update Request messages
definedas a single operation of an aircraft from takeoff
2.1(b) ேࡲࡓࡣᐙᒇࡢᐦ㞟ࡋ࡚࠸ࡿᆅᇦࡢୖ✵while ᨵṇ⯟✵ἲࡢᴫせ
enroute, the JAL5 was able to negotiate theto ࣭ᅜໃㄪᰝࡢ⤖ᯝࢆཷࡅタᐃࡉࢀ࡚࠸ࡿே
touchdown. The GUFI is intended to provide adiversion⯟✵ἲ➨᮲➨ 22stakeholders.
㡯࡟࠾࠸࡚↓ே⯟✵ᶵࡣ
with2 related
uniquereference to a specific flight. Its purpose is toḟࡢࡼ࠺࡟ᐃ⩏ࡉࢀ࡚࠸ࡿࠋ
ཱྀ㞟୰ᆅ༊ࡢୖ✵In this scenario, the two new messages, Update
assist in associating a message to the correct flight andRequest and Enroute Status are added for FF-ICE-1-75-

平成30年度（第18回）電子航法研究所研究発表会

平成30年度（第18回）電子航法研究所研究発表会

to help in distinguishing between similar flights.

data, and severe weather conditions to the eAU. Theࡍࡿ✵ᇦ࡟࠾ࡅࡿ⯟✵ᶵ㐠⯟࡟㛵ࡍࡿ⪃ᐹ
However, in the draft of FF-ICE/1
eASP evaluation and continuous monitoring of

ࡀ᪋⾜ࡉࢀ
↓ே⯟✵ᶵ
⬟࡞✵ᇦ࡟
ࠋ↓ே⯟✵
࡟࠾ࡅࡿᐁ
ቃᩚഛ࡟㛵
ᆺ↓ேᶵࡢ
ࡓࡵࡢไᗘ
ウ࡟࠾࠸࡚
㐍࡜Ᏻ඲☜
ࡉࢀ࡚࠸ࡿ
ே⯟✵ᶵ࡜
ࡉࢀࡘࡘ࠶
Ꮡᅾࡋ㸪✵
ࡣ࠸ࡃࡘࡶ

ࡘ࡜⪃࠼ࡽ
࠺࡞ᑠᆺ↓
⯟࡟ࡘ࠸࡚
ࡍࡿ⯟✵ᶵ
ࡍࡿྍ⬟ᛶ
ຍࡍࢀࡤ᥋
⏝ࡀಁ㐍ࡉ
ᆺ↓ேᶵࡀ
࡟ࡶ㸪᪩ᛴ
ࡢࡦ࡜ࡘ࡛

Implementation
Guidance, it doesͤᖹᯘ༤Ꮚ㸪⹡㇂኱ᆅnot specify GUFI in
Preliminary and Filed Flight Plans will check for and⯟✵஺㏻⟶⌮㡿ᇦ
Submission Response as a mandatory or optional field.
send message updates for changes to published┘ど㏻ಙ㡿ᇦ ἙᮧᬡᏊIncluding the GUFI allows participants to easily
constraints affecting the route. It not only assists theidentify Submission Responses as part of theirࠗࡇࡢἲᚊ࡟࠾࠸࡚ࠕ↓ே⯟✵ᶵࠖ࡜ࡣ㸪⯟respective FF-ICE/1 message conversations (as✵ࡢ⏝࡟౪ࡍࡿࡇ࡜ࡀ࡛ࡁࡿ㣕⾜ᶵ㸪ᅇ㌿
opposed to relying solely on the reference message ID),⩼⯟✵ᶵ㸪⁥✵ᶵ㸪㣕⾜⯪ࡑࡢ௚ᨻ௧࡛ᐃ
and allows developers to be consistent in theirࡵࡿᶵჾ࡛࠶ࡗ࡚ᵓ㐀ୖேࡀ஌ࡿࡇ࡜ࡀ࡛
implementations. It is therefore recommended that, atࡁ࡞࠸ࡶࡢࡢ࠺ࡕ㸪㐲㝸᧯సཪࡣ⮬ື᧯⦪
least duringinitial implementation, the GUFI should㸦ࣉࣟࢢ࣒ࣛ࡟ࡼࡾ⮬ືⓗ࡟᧯⦪ࢆ⾜࠺ࡇbe included
in all FF-ICE/1
messages.
࡜ࢆ࠸࠺ࠋ㸧࡟ࡼࡾ㣕⾜ࡉࡏࡿࡇ࡜ࡀ࡛ࡁࡿ
For
consistent and automatic message process inࡶࡢ㸦ࡑࡢ㔜㔞ࡑࡢ௚ࡢ஦⏤ࢆ຺᱌ࡋ࡚ࡑ
a certain
operation, each message should haveࡢ㣕⾜࡟ࡼࡾ⯟✵ᶵࡢ⯟⾜ࡢᏳ඲୪ࡧ࡟ᆅeAU in determining the optimal route/trajectory for aflight by identifying the operational environment andATM constraints applicable to the flight as proposed,
but also enables eASPs to obtain an earlier, moredetailed and more accurate assessment of the
anticipated traffic demand.
However, how to decide the relevant ASPs for acertain operation is not clearly defined in the related
documents. In the FF-ICE/1 Implementation Guidance,

different
message identifiers. A message identifiera relevant ASP is defined as any ASP who couldୖཬࡧỈୖࡢேཬࡧ≀௳ࡢᏳ඲ࡀᦆ࡞ࢃࢀ
allows ࡿ࠾ࡑࢀࡀ࡞࠸ࡶࡢ࡜ࡋ࡚ᅜᅵ஺㏻┬௧࡛identification of a message exchange between
potentially issue constraints on a flight. And the FFtwo parties.
And a message㸧ࢆ࠸࠺ࠋ
identifier between
twoᐃࡵࡿࡶࡢࢆ㝖ࡃࠋ࠘

ICE/1 Provisions states a relevant ASP is any ATM

parties should be unique for a certain operation or a ࡞࠾㸪Ᏻ඲ࡀᦆ࡞ࢃࢀࡿ࠾ࡑࢀࡀ࡞࠸ࡶࡢ
certaintime period.
In࡜ࡋ࡚ᅜᅵ஺㏻┬௧࡛ᐃࡵࡿࡶࡢࡣ㸪⯟✵ἲ
addition, to assure all stakeholders are using the᪋⾜つ๎㸦௨ୗ㸪ࠕ᪋⾜つ๎ࠖ࡜ࡍࡿࠋ
㸧࡟ࡼsame flight plan information,
the eAU is required
to
ࡾ㸪㔜㔞
200
ࢢ࣒ࣛᮍ‶࡜ࡉࢀ࡚࠸ࡿࠋ
provide an indication of the flight plan version. The
㣕⾜ࡢ࣮ࣝࣝ࡟㛵ࡋ࡚ࡣ㸪➨᮲㸦㣕⾜
flight planversion should be incremented 132
by theeAUࡢ⚗Ṇ✵ᇦ㸧
㸪➨132
᮲ࡢ
2㸦㣕⾜ࡢ᪉ἲ㸧each time a Flight Plan Update is submitted i.e. at least 㸪ཬࡧ➨1323㸦ᤚ⣴㸪ᩆຓ➼ࡢࡓࡵࡢ≉one flightplan
data᮲ࡢ
element
is changed. The flight plan౛㸧࡟ᐃࡵࡽࢀ࡚࠾ࡾ㸪㣕⾜⚗Ṇ✵ᇦࡢヲ⣽㸪version number is intended to provide both a reference୪ࡧ࡟㣕⾜⚗Ṇ✵ᇦ࡟࠾ࡅࡿ㣕⾜ࡢチྍཬࡧ
to a particular version but also an indication of the᪉ἲࡢヲ⣽࡟㛵ࡋ࡚ࡣ㸪᪋⾜つ๎࡛ᐃࡵࡽࢀ
sequence in which versions have been created. The last࡚࠸ࡿࠋᨵṇ⯟✵ἲ࡟࠾࠸࡚↓ே⯟✵ᶵࡀ㣕
flight plan version provided by the eAU to an eASP is⾜ࡍࡿ✵ᇦཬࡧ㣕⾜ࡢ᪉ἲ࡟㛵ࡍࡿᴫせ࡟ࡘ
expected to be included by the eASP when providing࠸࡚ㄝ᫂ࡍࡿࠋ
feedback in the form of a Submission Response or a
2.1.1 㣕⾜ࡍࡿ✵ᇦPlanning or Filing Status.
↓ே⯟✵ᶵࡀ㣕⾜ࡍࡿ࡟࠶ࡓࡾチྍࢆᚲせHowever,in the FIXM v4.0, the Flight Plan Version
࡜ࡍࡿ✵ᇦࡣ㸪ḟࡢ㏻ࡾ࡛࠶ࡿࠋ
field(a)is a freetext field without any mask. This can lead⯟✵ᶵࡢ⯟⾜ࡢᏳ඲࡟ᙳ㡪ࢆཬࡰࡍ࠾ࡑ
to incompatible
data in this field. It is recommendedࢀࡢ࠶ࡿ✵ᇦ

Service Provider whose airspace is along the flight

ࡘ࠸࡚
ࡀᐃ⩏ࡉࢀ
ἲ࡛ࡣ㸪↓
field should
be defined as an INTEGER and㣕⾜㸪ேཬ that this࣭✵➼ࡢ࿘㎶ࡢୖ✵ࡢ✵ᇦ
for processing the150m
incorrect
flight planࢆ┠ⓗ࡟ᐃ more details࣭ᆅ⾲ཪࡣỈ㠃࠿ࡽ௨ୖࡢ㧗ࡉࡢ✵version number
should be given in the implementation
ᇦplan route of flight or along the possible route of flightdescribed in filed routing to a revised destination. The
differentinterpretations

exist

withindifferent

participants to determine relevant ASPs who should
receive the flight plan from the originator. Further
examples would be helpful to clarify off-nominal cases
and avoid different interpretations of the FF-ICE/1
Implementation Guidance.
4. DISCUSSION
4.1 Interoperability
From the view of technical aspects, to achieve theinteroperability of SWIM services, the technicalinteroperability, the semantic interoperability and theprocess interoperability are required.
The technical interoperability is the basis of SWIM
concept-oriented operation. Based on acceptable
technology standards, the common and secure
infrastructurefornetwork

communication

andmessage exchange should be constructed at local,
guidance.
(b) ேࡲࡓࡣᐙᒇࡢᐦ㞟ࡋ࡚࠸ࡿᆅᇦࡢୖ✵ regional and global levels.
ே⯟✵ᶵࡣIn the࣭ᅜໃㄪᰝࡢ⤖ᯝࢆཷࡅタᐃࡉࢀ࡚࠸ࡿே
Lab exercise, there is an assumption that each
The implementation of semantic interoperability
eASP is ཱྀ㞟୰ᆅ༊ࡢୖ✵able to provide constraints, such as
requires the defined and precise meaning of exchanged
aeronautical information, traffic flow management

-1-

-76-

平成30年度（第18回）電子航法研究所研究発表会

information that can be preserved and understood by

Table 3. Problems and Challenges㸯㸬ᑠᆺ↓ேᶵࡀ㣕⾜ࡍࡿ✵ᇦ࡟࠾ࡅࡿ⯟✵ᶵ㐠⯟࡟㛵ࡍࡿ⪃ᐹ
allrelated stakeholders. And it need to bundle of
SWIM

information into meaningful messages based on the

FF-ICE

Problems and Challenges⯟✵஺㏻⟶⌮㡿ᇦ
Standards-based ͤᖹᯘ༤Ꮚ㸪⹡㇂኱ᆅ
Messaging infrastructure

different information exchange models that have been

Infrastructure

defined by ICAO. As a result, it enables new

Exchange

interoperable services to be identified, designed and1 ࡣࡌࡵ࡟
implemented based on the different information ᖹᡂ 27 ᖺ 12 ᭶࡟⯟✵ἲࡢᨵṇࡀ᪋⾜ࡉࢀ
exchange services.
࡚࠿ࡽ 2 ᖺ㏆ࡃࡀ⤒㐣ࡋ㸪ከࡃࡢ↓ே⯟✵ᶵ
To assure the consistent operation, the process࣮ࣘࢨ࣮ࡀ㣕⾜ࡢ࣮ࣝࣝ㸪㣕⾜ྍ⬟࡞✵ᇦ࡟
interoperability is necessary to perform actualࡘ࠸࡚ㄆ㆑ࡍࡿࡼ࠺࡟࡞ࡗ࡚ࡁࡓࠋ↓ே⯟✵
information exchange based on appropriate processᶵࡢ฼ά⏝ࡣ㸪㛵ಀ┬ᗇ㐃⤡఍㆟࡟࠾ࡅࡿᐁ
alignment. Coordinated and standardized processesẸ༠㆟఍࡟࠾࠸࡚㸪ᢏ⾡㛤Ⓨ࡜⎔ቃᩚഛ࡟㛵[1]enable SWIM responsible authorities
as well as㸪ᑠᆺ↓ேᶵࡢ
ࡍࡿ࣮ࣟࢻ࣐ࢵࣉࡀ♧ࡉࢀ
stakeholders to work together based on sufficiently฼⏝ࢆಁ㐍ࡋࡘࡘᏳ඲☜ಖࢆࡍࡿࡓࡵࡢไᗘ
aligned processes. Therefore, the metadata, format andసࡾࡢ᳨ウࡀ㐍ࡵࡽࢀ࡚࠸ࡿࠋ᳨ウ࡟࠾࠸࡚process of different messages should be defined inࡣ㸪ไᗘタィ࡟㛵ࡋ࡚ࡣ㸪฼⏝ಁ㐍࡜Ᏻ඲☜advance to ensure that eAUs and eASPs implement theಖࡢࣂࣛࣥࢫࢆ࡜ࡿࡇ࡜ࡀ㔜せ࡜ࡉࢀ࡚࠸ࡿ
[2]
globaloperation.
ࠋࡋ࠿ࡋ㸪ᨵṇ⯟✵ἲ࡟ࡼࡾ↓ே⯟✵ᶵ࡜⯟✵ᶵࡢ㣕⾜⠊ᅖࡀ࠶ࡿ⛬ᗘศ㞳ࡉࢀࡘࡘ࠶
4.2 Challengesࡿ୍᪉࡛㸪౛እ࡜࡞ࡿ㣕⾜ࡣከࡃᏑᅾࡋ㸪✵The SWIM-based FF-ICE operation will provideᇦ฼⏝⪅ࡢᏳ඲ࢆ☜ಖࡍࡿࡓࡵ࡟ࡣ࠸ࡃࡘࡶ
related information in greater detail and allow the eAUࡢㄢ㢟ࡀ࠶ࡿࠋ
the eASP to share their expectations in anandᮏ✏࡛ࡣ㸪ࡇࢀࡽࡢㄢ㢟ࡢࡦ࡜ࡘ࡜⪃࠼ࡽunambiguous manner via the exchange of trajectoryࢀࡿ㸪᫖௒ࢻ࣮ࣟࣥ࡜࿧ࡤࢀࡿࡼ࠺࡞ᑠᆺ↓information. However, as shown in Table 3, there areேᶵࡀ㣕⾜ࡍࡿ✵ᇦ࡛ࡢ⯟✵ᶵ㐠⯟࡟ࡘ࠸࡚still many problems
and challenges we should face to⪃ᐹࡍࡿࠋ✵
እࡢప㧗ᗘࢆ㣕⾜ࡍࡿ⯟✵ᶵ
achieve the FF-ICE oriented operation in local,࡜ᑠᆺ↓ேᶵࡢ㣕⾜࢚ࣜ࢔ࡀ➇ྜࡍࡿྍ⬟ᛶ
regional and global areas.
ࡀ࠶ࡾ㸪ᑠᆺ↓ேᶵࡢ㣕⾜ᩘࡀቑຍࡍࢀࡤ᥋
For standards-based interoperability, the routing㏆ࡍࡿ☜⋡ࡶ㧗ࡃ࡞ࡿࠋ௒ᚋ฼ά⏝ࡀಁ㐍ࡉࢀ㣕⾜㟂せࡀ㧗ࡲࡿ࡜ᛮࢃࢀࡿᑠᆺ↓ேᶵࡀ
standards between different systems to ensure message
㣕⾜ࡍࡿ࢚ࣜ࢔ࡢᏳ඲☜ಖࡢࡓࡵ࡟ࡶ㸪᪩ᛴ
delivery should be addressed. And for A/G SWIM࡟ྲྀࡾ⤌ࡲ࡞ࡅࢀࡤ࡞ࡽ࡞࠸ㄢ㢟ࡢࡦ࡜ࡘ࡛
integration, the coordination method between different
࠶ࡿࠋDMSs located in different places should be considered.
ᨵṇ⯟✵ἲ࡟ࡼࡿチྍᢎㄆ࡟ࡘ࠸࡚
2
For seamlessinformation sharing, additional guidance
is ᨵṇ⯟✵ἲ࡟ࡼࡾ㸪↓ே⯟✵ᶵࡀᐃ⩏ࡉࢀ
needed on translating between ATS and FF-ICE㣕⾜ࡢ࣮ࣝࣝࡀᩚ⌮ࡉࢀࡓࠋ⯟✵ἲ࡛ࡣ㸪↓messages to avoid ambiguity and data loss. It wasே⯟✵ᶵࡢ㣕⾜ࡀ㸪᭷ே⯟✵ᶵࡢ㣕⾜㸪ேཬobserved that not all elements map one-to-one betweenࡧ≀௳➼࡟ᙳ㡪ࢆཬࡤࡉ࡞࠸ࡇ࡜ࢆ┠ⓗ࡟ᐃ
ATS and FF-ICE messages and this can result inࡵࡽࢀ࡚࠸ࡿࠋ
misinterpretation between translators and message
2.1 ᨵṇ⯟✵ἲࡢᴫせ
consumers. And the data and information to improve ⯟✵ἲ➨ 2 ᮲➨ 22 㡯࡟࠾࠸࡚↓ே⯟✵ᶵࡣ
A/G SWIM integration should be defined in theḟࡢࡼ࠺࡟ᐃ⩏ࡉࢀ࡚࠸ࡿࠋ
current standard information exchange models. For-1-77-

ἙᮧᬡᏊInteroperability┘ど㏻ಙ㡿ᇦ
for FF-ICE operation
Seamless

FIXM-based definition

Modelsinformation sharing
for FF-ICE messages
ࠗࡇࡢἲᚊ࡟࠾࠸࡚ࠕ↓ே⯟✵ᶵࠖ࡜ࡣ㸪⯟✵ࡢ⏝࡟౪ࡍࡿࡇ࡜ࡀ࡛ࡁࡿ㣕⾜ᶵ㸪ᅇ㌿Exchange
Situation-awareness Heterogeneous services⩼⯟✵ᶵ㸪⁥✵ᶵ㸪㣕⾜⯪ࡑࡢ௚ᨻ௧࡛ᐃ
Services
service cooperation
provision and utilizationࡵࡿᶵჾ࡛࠶ࡗ࡚ᵓ㐀ୖேࡀ஌ࡿࡇ࡜ࡀ࡛
Definition for quality,
Life-cycleࡁ࡞࠸ࡶࡢࡢ࠺ࡕ㸪㐲㝸᧯సཪࡣ⮬ື᧯⦪security and businessGovernancemanagement㸦ࣉࣟࢢ࣒ࣛ࡟ࡼࡾ⮬ືⓗ࡟᧯⦪ࢆ⾜࠺ࡇrules࡜ࢆ࠸࠺ࠋ㸧࡟ࡼࡾ㣕⾜ࡉࡏࡿࡇ࡜ࡀ࡛ࡁࡿ
ࡶࡢ㸦ࡑࡢ㔜㔞ࡑࡢ௚ࡢ஦⏤ࢆ຺᱌ࡋ࡚ࡑ
situation-awareness service cooperation, it is requiredࡢ㣕⾜࡟ࡼࡾ⯟✵ᶵࡢ⯟⾜ࡢᏳ඲୪ࡧ࡟ᆅ
to establish a common format for referencingୖཬࡧỈୖࡢேཬࡧ≀௳ࡢᏳ඲ࡀᦆ࡞ࢃࢀ
constraints in AIXM and iWXXM over the differentࡿ࠾ࡑࢀࡀ࡞࠸ࡶࡢ࡜ࡋ࡚ᅜᅵ஺㏻┬௧࡛
systems.
ᐃࡵࡿࡶࡢࢆ㝖ࡃࠋ㸧ࢆ࠸࠺ࠋ࠘
Moreover, to facilitate interoperability andharmonization
and avoid integration issues, it was ࡞࠾㸪Ᏻ඲ࡀᦆ࡞ࢃࢀࡿ࠾ࡑࢀࡀ࡞࠸ࡶࡢ
necessaryfor participants to share a common, agreed࡜ࡋ࡚ᅜᅵ஺㏻┬௧࡛ᐃࡵࡿࡶࡢࡣ㸪⯟✵ἲ
upon
set of business/datarules which were㸧࡟ࡼ
derived᪋⾜つ๎㸦௨ୗ㸪ࠕ᪋⾜つ๎ࠖ࡜ࡍࡿࠋ
fromthe FF-ICE/1
Provisions and Implementationࡾ㸪㔜㔞
200 ࢢ࣒ࣛᮍ‶࡜ࡉࢀ࡚࠸ࡿࠋ
Guidance.
Participants could validate 132
messagesusing 㣕⾜ࡢ࣮ࣝࣝ࡟㛵ࡋ࡚ࡣ㸪➨᮲㸦㣕⾜methods
compatible
and resources,㸪asࡢ⚗Ṇ✵ᇦ㸧
㸪➨ with132 their᮲ࡢneeds2㸦㣕⾜ࡢ᪉ἲ㸧longas thevalidation
method used the common set ofཬࡧ➨132᮲ࡢ 3㸦ᤚ⣴㸪ᩆຓ➼ࡢࡓࡵࡢ≉౛㸧࡟ᐃࡵࡽࢀ࡚࠾ࡾ㸪㣕⾜⚗Ṇ✵ᇦࡢヲ⣽㸪businessrules. This helped
avoid issues where୪ࡧ࡟㣕⾜⚗Ṇ✵ᇦ࡟࠾ࡅࡿ㣕⾜ࡢチྍཬࡧ
participants
may have interpreted the FF-ICE/1
᪉ἲࡢヲ⣽࡟㛵ࡋ࡚ࡣ㸪᪋⾜つ๎࡛ᐃࡵࡽࢀ
Implementation
Guidance and related documents in࡚࠸ࡿࠋᨵṇ⯟✵ἲ࡟࠾࠸࡚↓ே⯟✵ᶵࡀ㣕different ways.
⾜ࡍࡿ✵ᇦཬࡧ㣕⾜ࡢ᪉ἲ࡟㛵ࡍࡿᴫせ࡟ࡘ
5.
CONCLUSIONS࠸࡚ㄝ᫂ࡍࡿࠋ

2.1.1
In this㣕⾜ࡍࡿ✵ᇦpaper, the overview of IIH&V international↓ே⯟✵ᶵࡀ㣕⾜ࡍࡿ࡟࠶ࡓࡾチྍࢆᚲせproject for validating FF-ICE oriented operation is࡜ࡍࡿ✵ᇦࡣ㸪ḟࡢ㏻ࡾ࡛࠶ࡿࠋ
introduced.
And the development and analysis of Lab(a) ⯟✵ᶵࡢ⯟⾜ࡢᏳ඲࡟ᙳ㡪ࢆཬࡰࡍ࠾ࡑ
exercises of Validation 1 and 2/3 related to the regionalࢀࡢ࠶ࡿ✵ᇦ
implementation is reported. In addition, according to a࣭✵ ➼ࡢ࿘㎶ࡢୖ✵ࡢ✵ᇦcertain scenario, the operational processes, procedures,࣭ᆅ⾲ཪࡣỈ㠃࠿ࡽ 150m ௨ୖࡢ㧗ࡉࡢ✵and automation changes required for FF-ICE provisionᇦ
implementation between ASPs, AUs, and aviation(b) ேࡲࡓࡣᐙᒇࡢᐦ㞟ࡋ࡚࠸ࡿᆅᇦࡢୖ✵stakeholders are clarified. Finally, the problems and࣭ᅜໃㄪᰝࡢ⤖ᯝࢆཷࡅタᐃࡉࢀ࡚࠸ࡿே
challenges
for constructing the FF-ICE operatingཱྀ㞟୰ᆅ༊ࡢୖ✵environment to achieve interoperability are discussed.

平成30年度（第18回）電子航法研究所研究発表会

平成30年度（第18回）電子航法研究所研究発表会

ACKNOWLEDGEMENT[7] FAA, “Validating ICAO Provisions via Tabletop
Exercises - Update,” ATMRPP/5, ICAO, March2018.
if we did ⯟✵஺㏻⟶⌮㡿ᇦ
not have a support ͤᖹᯘ༤Ꮚ㸪⹡㇂኱ᆅof JCAB and other[8] FAA, “Tabletop Exercise Findings on FF-ICE
organizations. Therefore, we would
like to extend
our┘ど㏻ಙ㡿ᇦ
ἙᮧᬡᏊPlanning Trial Request Provisions,” ATMRPP/5,
sincere gratitude to all of them.
ICAO, March 2018.
ࠗࡇࡢἲᚊ࡟࠾࠸࡚ࠕ↓ே⯟✵ᶵࠖ࡜ࡣ㸪⯟ [9] Global Air Traffic Management (ATM)REFERENCES✵ࡢ⏝࡟౪ࡍࡿࡇ࡜ࡀ࡛ࡁࡿ㣕⾜ᶵ㸪ᅇ㌿Operational Concept, ICAO Doc. 9854, 1st ed.,[1] Manual on Flight and Flow - Information for a⩼⯟✵ᶵ㸪⁥✵ᶵ㸪㣕⾜⯪ࡑࡢ௚ᨻ௧࡛ᐃICAO, 2005.
Collaborative Environment, ICAO Doc. 9965,
ࡵࡿᶵჾ࡛࠶ࡗ࡚ᵓ㐀ୖேࡀ஌ࡿࡇ࡜ࡀ࡛ [10]X.D Lu, T. Koga and Y. Sumiya, “Coordinated
ICAO, 2012.
ࡁ࡞࠸ࡶࡢࡢ࠺ࡕ㸪㐲㝸᧯సཪࡣ⮬ື᧯⦪
Validationfor
SWIM
Concept-Oriented[2] Manual on System Wide Information㸦ࣉࣟࢢ࣒ࣛ࡟ࡼࡾ⮬ືⓗ࡟᧯⦪ࢆ⾜࠺ࡇ
Operation to Achieve Interoperability,” ENRI Int.
Management (SWIM) Concept, ICAO Doc 10039,
࡜ࢆ࠸࠺ࠋ㸧࡟ࡼࡾ㣕⾜ࡉࡏࡿࡇ࡜ࡀ࡛ࡁࡿ
Workshop on ATM/CNS, November 2017.
ICAO, 2015.
ࡶࡢ㸦ࡑࡢ㔜㔞ࡑࡢ௚ࡢ஦⏤ࢆ຺᱌ࡋ࡚ࡑ [11]ENRI, “International and Regional Coordination[3] 2016-2030 Global Air Navigation Plan, ICAOࡢ㣕⾜࡟ࡼࡾ⯟✵ᶵࡢ⯟⾜ࡢᏳ඲୪ࡧ࡟ᆅ
for FF-ICE/1 Validation,” SWIM-TF/1-IP/02,
Doc 9750, 5th ed., ICAO, 2016.
ୖཬࡧỈୖࡢேཬࡧ≀௳ࡢᏳ඲ࡀᦆ࡞ࢃࢀICAO, May 2017.
[4] Procedures for Air Navigation Services - Airࡿ࠾ࡑࢀࡀ࡞࠸ࡶࡢ࡜ࡋ࡚ᅜᅵ஺㏻┬௧࡛ [12]ENRI, “Lab Exercise for FF-ICE/1 and A/G
Traffic Management, ICAO Doc 4444, 15th ed.,ᐃࡵࡿࡶࡢࢆ㝖ࡃࠋ㸧ࢆ࠸࠺ࠋ࠘SWIM Validation,” SWIM-TF/2-IP/06, ICAO,ICAO, 2007.
April 2018.
[5] FAA, “Validating ICAO Provisions via Tabletop ࡞࠾㸪Ᏻ඲ࡀᦆ࡞ࢃࢀࡿ࠾ࡑࢀࡀ࡞࠸ࡶࡢ [13]X.D Lu and T. Koga, “System Wide Information
Exercises,” ATMRPP/2-IP/01, ICAO, 2016.
࡜ࡋ࡚ᅜᅵ஺㏻┬௧࡛ᐃࡵࡿࡶࡢࡣ㸪⯟✵ἲ
Management for Heterogeneous Information[6] FAA, “Validating ICAO Provisions via Tabletop᪋⾜つ๎㸦௨ୗ㸪ࠕ᪋⾜つ๎ࠖ࡜ࡍࡿࠋ㸧࡟ࡼ
Sharing and Interoperability,” IEEE 13th
Exercises - Update,” ATMRPP-WG/32-IP/08,
ࡾ㸪㔜㔞 200 ࢢ࣒ࣛᮍ‶࡜ࡉࢀ࡚࠸ࡿࠋ
International Symposium on Autonomous
ICAO, October 2017.
 㣕⾜ࡢ࣮ࣝࣝ࡟㛵ࡋ࡚ࡣ㸪➨ 132 ᮲㸦㣕⾜
Decentralized Systems, March 2017, pp. 199-204.
ࡢ⚗Ṇ✵ᇦ㸧㸪➨ 132 ᮲ࡢ 2㸦㣕⾜ࡢ᪉ἲ㸧㸪ཬࡧ➨ 132 ᮲ࡢ 3㸦ᤚ⣴㸪ᩆຓ➼ࡢࡓࡵࡢ≉౛㸧࡟ᐃࡵࡽࢀ࡚࠾ࡾ㸪㣕⾜⚗Ṇ✵ᇦࡢヲ⣽㸪୪ࡧ࡟㣕⾜⚗Ṇ✵ᇦ࡟࠾ࡅࡿ㣕⾜ࡢチྍཬࡧ᪉ἲࡢヲ⣽࡟㛵ࡋ࡚ࡣ㸪᪋⾜つ๎࡛ᐃࡵࡽࢀ
࡚࠸ࡿࠋᨵṇ⯟✵ἲ࡟࠾࠸࡚↓ே⯟✵ᶵࡀ㣕⾜ࡍࡿ✵ᇦཬࡧ㣕⾜ࡢ᪉ἲ࡟㛵ࡍࡿᴫせ࡟ࡘ࠸࡚ㄝ᫂ࡍࡿࠋ
2.1.1 㣕⾜ࡍࡿ✵ᇦ↓ே⯟✵ᶵࡀ㣕⾜ࡍࡿ࡟࠶ࡓࡾチྍࢆᚲせ࡜ࡍࡿ✵ᇦࡣ㸪ḟࡢ㏻ࡾ࡛࠶ࡿࠋ
(a) ⯟✵ᶵࡢ⯟⾜ࡢᏳ඲࡟ᙳ㡪ࢆཬࡰࡍ࠾ࡑ
ࢀࡢ࠶ࡿ✵ᇦ࣭✵ ➼ࡢ࿘㎶ࡢୖ✵ࡢ✵ᇦ࣭ᆅ⾲ཪࡣỈ㠃࠿ࡽ 150m ௨ୖࡢ㧗ࡉࡢ✵ᇦ(b) ேࡲࡓࡣᐙᒇࡢᐦ㞟ࡋ࡚࠸ࡿᆅᇦࡢୖ✵࣭ᅜໃㄪᰝࡢ⤖ᯝࢆཷࡅタᐃࡉࢀ࡚࠸ࡿே
ཱྀ㞟୰ᆅ༊ࡢୖ✵ࡍࡿ✵ᇦ࡟࠾ࡅࡿ⯟✵ᶵ㐠⯟࡟㛵ࡍࡿ⪃ᐹThis development would not have been implemented

ࡀ᪋⾜ࡉࢀ
↓ே⯟✵ᶵ
⬟࡞✵ᇦ࡟
ࠋ↓ே⯟✵
࡟࠾ࡅࡿᐁ
ቃᩚഛ࡟㛵
ᆺ↓ேᶵࡢ
ࡓࡵࡢไᗘ
ウ࡟࠾࠸࡚
㐍࡜Ᏻ඲☜
ࡉࢀ࡚࠸ࡿ
ே⯟✵ᶵ࡜
ࡉࢀࡘࡘ࠶
Ꮡᅾࡋ㸪✵
ࡣ࠸ࡃࡘࡶ

ࡘ࡜⪃࠼ࡽ
࠺࡞ᑠᆺ↓
⯟࡟ࡘ࠸࡚
ࡍࡿ⯟✵ᶵ
ࡍࡿྍ⬟ᛶ
ຍࡍࢀࡤ᥋
⏝ࡀಁ㐍ࡉ
ᆺ↓ேᶵࡀ
࡟ࡶ㸪᪩ᛴ
ࡢࡦ࡜ࡘ࡛

ࡘ࠸࡚
ࡀᐃ⩏ࡉࢀ
ἲ࡛ࡣ㸪↓
㣕⾜㸪ேཬ
ࢆ┠ⓗ࡟ᐃ

ே⯟✵ᶵࡣ

-1-

-78-