測距・追跡#85

航法データメッセージ標準 — CCSDS ODM/ADMによる軌道・姿勢情報の機関間交換

測距・ドップラー・DDORから重み付き最小二乗法で推定した軌道状態ベクトルを、別の機関・別のソフトウェアツールへどう渡すかを扱う回。座標系やエポックの取り違えが実際に致命的な事故を招いてきた歴史を踏まえ、CCSDS Orbit Data Message(OEM/OPM/OMM)とAttitude Data Message(ADM)という航法データの標準交換フォーマット群を、そのメタデータ構造とともに整理する。

前提知識: 測距・ドップラー・DDORの統合 — 幾何学的DOPと最小二乗法による軌道決定

CCSDSODM軌道決定相互運用性データフォーマット

この回で学ぶこと

前々回の軌道決定の回では、測距・ドップラー・DDORという3種類の観測量から、重み付き最小二乗法によって探査機の6次元状態ベクトル $\delta\hat{\mathbf{x}}_0=(H^TWH)^{-1}H^TW\Delta\mathbf{z}$ とその推定誤差共分散行列 $P=(H^TWH)^{-1}$ を求める手続きを学びました。この回で扱うのは、その「計算そのもの」ではありません。計算が終わったあとの話です。ある地上局・ある運用チームが精魂込めて推定した軌道状態ベクトルと共分散行列は、多くの場合そのチーム内だけで完結しません。国際協力ミッションであれば別の宇宙機関の航法チームへ、商用衛星運用であれば別の事業者の衝突回避システムへ、あるいは単に自分たちの中でも解析ソフトウェアが変われば別のツールへと、この数値の集まりを受け渡す必要が出てきます。

ここで問題になるのが、国際相互運用の回で見た議論の、また別のレイヤーでの再現です。あの回では、変調方式やフレームフォーマットが標準化されていなければ探査機と地上局が「電波レベルで会話できない」ことを見ました。今回の問題はその一段上、つまり電波を通じて無事にビット列が届き、軌道決定という計算も正しく行われたあとで、その計算結果である「数値の集まり」を人間やソフトウェアがどう解釈するか、という層で起きます。極端な言い方をすれば、テキストファイルに並んだ6つの数字 6678.14, 0.0, 0.0, 0.0, 7.726, 0.0 を見せられたとき、これが位置3成分・速度3成分だと察しがついたとしても、「どの座標系での値か」「どの時刻(いつのエポック)の値か」「単位はkmかmか」が書かれていなければ、その数字は実質的に無意味です。

この回では、こうした軌道情報(および関連する姿勢情報)を機関・ソフトウェアの垣根を越えて交換するために、CCSDSが整備してきた**Orbit Data Message(ODM)ファミリーとAttitude Data Message(ADM)**を扱います。OEM・OPM・OMMという3つのメッセージ形式がそれぞれ何を運ぶために使い分けられているのか、そしてなぜ「座標系・基準系を明示するメタデータ」がデータそのものと同じくらい、あるいはそれ以上に重要なのかを、過去の事故例も交えながら見ていきます。

直感的導入: 数字の羅列は、文脈なしには軌道にならない

想像してみてください。あなたはある探査機の航法チームの一員で、前々回の手続きに従って軌道決定を行い、推定された状態ベクトルをメールに添付して、共同ミッションを組んでいる別の宇宙機関の航法チームに送るとします。添付ファイルの中身が、単に

6678.140  0.000  0.000  0.000  7.726  0.000

という1行のテキストだったらどうなるでしょうか。受け取った側は、これが位置と速度の6成分らしいことは推測できても、次のような疑問にすぐ突き当たります。

単位はkmとkm/sか、それともmとm/sか(あるいは古い資料ならフィートやマイルという可能性すらあります)。
基準とする中心天体は地球か、太陽系重心か、探査対象の天体か。
座標系は慣性系(たとえばJ2000.0元期の地球中心慣性系)か、地球の自転とともに回る地球固定系か。
この状態ベクトルは「いつ」の時刻における値か。そしてその時刻はUTCか、TAIか、力学時TDBか。

これらの答えが1つでも食い違えば、送り手が意図した軌道とはまったく異なる軌道として解釈されてしまいます。しかも厄介なことに、多くの場合これは気づかれないまま起こります。数字はそれらしい大きさのまま計算に投入され、結果はそれらしい形の答えを出し、しかしその答えは静かに間違っている——これが、標準化されていないデータ交換が持つ本当の危険性です。国際相互運用の回で見た「電波が受信できない」という失敗は少なくとも派手に失敗するので気づきやすいのに対し、こちらの失敗は気づかれにくいまま静かに軌道を狂わせるという点で、ある意味さらに危険です。

CCSDSはこの問題に対して、国際相互運用の回で見たのと同じ発想——各機関が独自にファイル形式を決めるのではなく、共通の標準フォーマットに合わせることでコストを $O(N^2)$ から $O(N)$ に落とす——を、物理層やプロトコル層だけでなく、この「軌道・姿勢データそのものの表現形式」というアプリケーション層にまで適用しました。それが今回扱うNavigation Data Messageの標準群です。

定式化・整理その1: ODMファミリーの3形式 — OEM・OPM・OMM

CCSDSのOrbit Data Message標準(CCSDS 502.0-B)は、単一のファイル形式ではなく、運ぶべき情報の性質が異なる3つのメッセージ形式の集合として定義されています。これは、前々回で求めた軌道決定の結果が、用途によって「どういう形の情報」として欲しいかが変わるためです。

OPM(Orbit Parameter Message) — ある一瞬のスナップショット

OPMは、ある1つのエポック(基準時刻)における状態ベクトル(あるいは古典軌道要素)を1組だけ運ぶ、最も軽量なメッセージ形式です。前々回の言葉で言えば、軌道決定バッチ処理を1回まわして得られた $\delta\hat{\mathbf{x}}_0$ を基準軌道に足し合わせた「その時点でのベスト推定値」1点だけを、機関間で受け渡すのに使います。OPMの典型的な構造(KVN: Keyword Value Notationという、CCSDSが定めるテキスト表現)は次のようになります。

CCSDS_OPM_VERS = 3.0
CREATION_DATE  = 2026-07-10T12:00:00
ORIGINATOR     = NAV-TEAM-A

META_START
OBJECT_NAME    = EXAMPLE-SC
OBJECT_ID      = 2024-001A
CENTER_NAME    = EARTH
REF_FRAME      = EME2000
TIME_SYSTEM    = UTC
META_STOP

EPOCH  = 2026-07-10T00:00:00
X      =  6678.140  [km]
Y      =     0.000  [km]
Z      =     0.000  [km]
X_DOT  =     0.000  [km/s]
Y_DOT  =     7.726  [km/s]
Z_DOT  =     0.000  [km/s]

COV_START
COV_REF_FRAME = EME2000
CX_X  =  1.2e-02
CY_X  =  3.1e-04
CY_Y  =  8.7e-03
...
COV_STOP

先頭のヘッダに続く META_START〜META_STOP ブロックが、まさに前節で挙げた「座標系」「時刻系」「基準天体」を明示するメタデータです。REF_FRAME = EME2000 は「西暦2000年元期地球平均赤道・分点座標系」という慣性系を、TIME_SYSTEM = UTC は時刻系を、CENTER_NAME = EARTH は原点天体を、それぞれ曖昧さなく指定します。さらに注目すべきは、OPMにはオプションで COV_START/COV_STOP ブロックが用意されている点です。ここには前々回で導出した共分散行列 $P=(H^TWH)^{-1}$ の下三角成分をそのまま格納できます。つまりOPMは、単なる状態ベクトルの受け渡しにとどまらず、「その推定がどれだけ信頼できるか」という誤差楕円体の情報までを標準形式で運ぶことができる設計になっています。

OEM(Orbit Ephemeris Message) — 時刻ごとの状態ベクトルの系列

OEMは、OPMのような単一時刻のスナップショットではなく、ある時間範囲にわたる状態ベクトルの系列(エフェメリス、ephemeris)を運びます。データブロックの中身はOPMの EPOCH 行以降がそのまま複数行繰り返される形になります。

META_START
OBJECT_NAME  = EXAMPLE-SC
OBJECT_ID    = 2024-001A
CENTER_NAME  = EARTH
REF_FRAME    = EME2000
TIME_SYSTEM  = UTC
START_TIME   = 2026-07-10T00:00:00
STOP_TIME    = 2026-07-17T00:00:00
INTERPOLATION       = LAGRANGE
INTERPOLATION_DEGREE = 7
META_STOP

2026-07-10T00:00:00.000  6678.140  0.000  0.000  0.000  7.726  0.000
2026-07-10T00:10:00.000  6650.221  897.4  0.000 -0.980  7.700  0.000
2026-07-10T00:20:00.000  6566.9   1789.3  0.000 -1.955  7.622  0.000
...

なぜスナップショット(OPM)だけでなく、系列(OEM)が必要なのでしょうか。それは、多くの実務的な用途が「ある一瞬の位置」ではなく「ある時間範囲にわたる軌跡全体」を必要とするからです。後述する衝突回避のためのコンジャンクション評価(conjunction assessment)はその典型例で、2つの物体の軌道が今後数日間にわたってどれだけ接近するかを評価するには、両者の軌道を連続的な(あるいは高頻度にサンプリングされた)エフェメリスとして比較しなければなりません。OEMのメタデータには INTERPOLATION フィールドがあり、離散的な時刻の点列から連続的な軌道を復元する際にどの補間法(ラグランジュ補間など)と次数を使うべきかまで指定できるようになっている点も、単なる数値羅列との大きな違いです。

OMM(Orbit Mean-elements Message) — 平均軌道要素

OMMは、状態ベクトル(位置・速度の直交座標)ではなく、離心率・軌道傾斜角・昇交点赤経・近地点引数・平均近点角・平均運動といった**平均軌道要素(mean elements)**の組を運びます。構造としてはOPMに近い単一スナップショットですが、中身が根本的に異なります。

META_START
OBJECT_NAME          = EXAMPLE-SC
OBJECT_ID            = 2024-001A
CENTER_NAME          = EARTH
REF_FRAME            = TEME
TIME_SYSTEM          = UTC
MEAN_ELEMENT_THEORY  = SGP4
META_STOP

EPOCH                =  2026-07-10T00:00:00
MEAN_MOTION          =  15.50103472  [rev/day]
ECCENTRICITY         =  0.0007112
INCLINATION          =  51.6423  [deg]
RA_OF_ASC_NODE       = 247.4627  [deg]
ARG_OF_PERICENTER    = 130.5360  [deg]
MEAN_ANOMALY         = 325.0777  [deg]

OMMは、いわゆるTLE(Two-Line Element)が運んできたのと同種の情報を、CCSDSの標準構造の中で表現しなおしたものだと考えると理解しやすいでしょう。TLEはフォーマットが1970年代から続く固定長のテキスト形式で、機関間交換用の標準として設計されたものではありません。OMMは同じ「平均要素+摂動理論」の考え方を、MEAN_ELEMENT_THEORY(たとえばSGP4)を明示メタデータとして持つ形に標準化したものです。ここが重要な点で、平均要素はどの摂動理論(伝播モデル)を前提にしているかによって数値の意味が変わるため、OEM/OPMの座標系情報と同じ重みで、この理論の指定が不可欠になります。

3形式の使い分け

形式	運ぶ情報	典型的な用途
OPM	単一エポックの状態ベクトル(+共分散)	軌道決定結果の1点受け渡し、探査機の現在の最良推定軌道の通知
OEM	時系列の状態ベクトル	コンジャンクション評価、ミッション計画、可視性解析など連続軌道が必要な用途
OMM	平均軌道要素+摂動理論	カタログ管理、SGP4系の高速伝播、多数物体の軽量な軌道情報配信

前々回の軌道決定の出力そのものは状態ベクトル $\hat{\mathbf{x}}_0$ とその共分散 $P$ でしたから、素直にはOPMで表現するのが最も対応が良い形です。しかしその軌道を伝播した結果を数日先まで見せたい、あるいは複数物体の軌道を比較したいという用途になると、同じ情報をOEMとして(内部的に力学モデルで伝播しながら)出力しなおす必要が出てきます。逆に、精密な状態ベクトルではなく「大まかな公開カタログ情報」として広く配信したい場合はOMMが選ばれます。3形式はどれか1つが優れているという関係ではなく、同じ軌道決定という営みの出力を、受け手の用途に応じて異なる粒度・異なる表現で切り出したものだと理解するのが正確です。

定式化・整理その2: 姿勢版としてのADM

軌道(位置・速度)だけでなく、探査機の姿勢(向き)も機関間で交換される情報です。CCSDSはこれに対応するために**Attitude Data Message(ADM、CCSDS 504.0-B)を定義しており、構造の考え方はODMとほぼ並行しています。単一エポックの姿勢を運ぶAPM(Attitude Parameter Message)がOPMに、時系列の姿勢を運ぶAEM(Attitude Ephemeris Message)**がOEMに、それぞれ対応します(平均要素に相当するものは姿勢には存在しないため、OMMに対応するものはありません)。

META_START
OBJECT_NAME    = EXAMPLE-SC
REF_FRAME_A    = EME2000
REF_FRAME_B    = SC_BODY_1
ATTITUDE_TYPE  = QUATERNION
META_STOP

EPOCH = 2026-07-10T00:00:00
Q1 = 0.0341   Q2 = -0.1187   Q3 = 0.5502   QC = 0.8261

ここでも REF_FRAME_A(基準となる外部座標系)と REF_FRAME_B(探査機本体に固定された座標系)という2つの座標系が明示され、クォータニオン $(Q_1,Q_2,Q_3,Q_C)$ が「どの系からどの系への回転を表すか」が曖昧さなく定まるようになっています。姿勢情報は、たとえばアンテナの指向精度の検証や、アンテナ自動追尾のような地上局側の運用、あるいは科学観測データの幾何補正(カメラがどちらを向いていたときの画像か)などで機関間・チーム間の受け渡しが必要になり、ODMと同じ標準化の恩恵を必要としています。

定式化・整理その3: 基準系メタデータの重み — なぜ「数値以上に大事」なのか

ここまで繰り返し強調してきた「座標系・時刻系のメタデータ」が、実際にどれほどの誤差を生みうるかを定量的に見積もってみましょう。

座標系の取り違え

地球中心慣性系(たとえばEME2000のような準慣性系)と地球固定系(ITRF系のように地球の自転とともに回転する系)は、ある瞬間には角度 $\theta_{\rm GMST}(t)$ (グリニッジ平均恒星時)だけ、地球の自転軸まわりに回転してずれています。もし送り手が地球固定系で書き出した状態ベクトルを、受け手が「REF_FRAMEの指定がないから」と誤って慣性系のまま使ってしまうと、位置ベクトルの取り違えによる誤差は、半径 $r$ の円上の2点を角度 $\theta_{\rm GMST}$ だけ回転させた弦の長さとしておおよそ

\Delta r \approx 2r\sin\!\left(\frac{\theta_{\rm GMST}}{2}\right)

と見積もれます。静止軌道( $r\approx 42{,}164\ \text{km}$ )にある衛星を例に、エポックから6時間後(地球はその間に約90°自転する、つまり $\theta_{\rm GMST}\approx 90°$ )の状態を取り違えたとすると、

\Delta r \approx 2\times 42{,}164 \times \sin(45°) \approx 2 \times 42{,}164 \times 0.707 \approx 59{,}600\ \text{km}

となり、これは軌道半径そのものと同程度の、事実上「まったく無関係な場所にいる」ほどの誤差です。前々回で議論した軌道決定の推定誤差(良い幾何配置でも数百m〜数km程度)とは比較にならない規模の誤りが、たった1つのメタデータの欠落・誤読から生まれることが分かります。

時刻系の取り違え

時刻系の違いも軽視できません。協定世界時UTCと国際原子時TAIの間には、うるう秒の累積によって現在37秒(2016年以降据え置き)のずれがあります。静止軌道の軌道速度はおよそ $v\approx 3.07\ \text{km/s}$ ですから、時刻系を取り違えて37秒分だけ古い(あるいは新しい)状態を使ってしまうと、

\Delta r \approx v\,\Delta t \approx 3.07\ \text{km/s} \times 37\ \text{s} \approx 114\ \text{km}

という、決して無視できない誤差が生じます。ODMの TIME_SYSTEM フィールドがUTC・TAI・TDB(太陽系力学時)・TT(地球時)などを明示的に区別するのは、この種の誤差を防ぐためです。

単位系の取り違え — Mars Climate Orbiterの教訓

座標系・時刻系だけでなく、単位系の取り違えが実際に探査機を失う事故につながった例として、1999年の**Mars Climate Orbiter(MCO)**の喪失事故が広く知られています。この事故では、探査機の姿勢制御スラスタが発生させる力積(インパルス)のデータを、地上のある解析ソフトウェアがヤード・ポンド法の単位(重量ポンド秒、lbf·s)で出力していたのに対し、その値を受け取って軌道決定に使う別の航法ソフトウェアはメートル法の単位(ニュートン秒、N·s)として解釈していました。1 lbf·s ≈ 4.45 N·s ですから、これは実質的に力積を4.45倍過大評価したまま軌道計算が進んだことを意味し、火星到達時の軌道が計画よりも大幅に低い高度を通過することになり、探査機は火星大気圏で破壊されたと結論づけられています。

MCOの事故そのものはCCSDSのODM標準(2002年制定)以前の出来事であり、直接ODMが原因を防いだわけではありません。しかし、この事故が業界全体に突きつけた教訓——「数値だけを渡してはいけない。単位・基準系・時刻系を、機械可読な形で必ず添えなければならない」——は、その後の航法データ交換標準の設計思想に色濃く反映されています。ODMの各メッセージが [km]・[km/s] のような単位を明示し、REF_FRAME や TIME_SYSTEM を必須に近いメタデータとして位置づけているのは、まさにこの種の事故を二度と起こさないための設計です。

実務での使われ方

コンジャンクション評価(衝突回避)におけるOEM/CDM交換

現代の宇宙状況把握(Space Situational Awareness, SSA)の中核的な業務の1つが、軌道上の物体同士がどれだけ接近するかを予測する**コンジャンクション評価(conjunction assessment)**です。米宇宙軍の第18宇宙防衛飛行隊(18th Space Defense Squadron)は、追跡している全カタログ物体のOEM相当のエフェメリスから2物体間の接近を検知すると、**Conjunction Data Message(CDM、CCSDS 508.0-B)**という、やはりCCSDSが標準化したメッセージ形式で該当する衛星運用者に通知します。CDMの内部にも、接近する2物体それぞれの状態ベクトル・共分散・基準系がODMと同じ思想で記述されており、運用者はこれを自社の軌道力学ソフトウェアに読み込んで、回避操作(コリジョンアボイダンス・マニューバ)の要否を判断します。もしこの通知が標準化されていない独自フォーマットで届いていたら、事業者ごとに解釈用の変換ソフトウェアを個別開発する必要が生じ、国際相互運用の回で見た「相対型アプローチ」の組合せ爆発がここでも再現されていたはずです。NASAの衝突回避リスク分析チーム(CARA)も、複数機関のミッション(ISS、各種科学衛星)を対象にこの標準フォーマットでのデータ交換を前提とした運用を行っています。

国際協力ミッションでの軌道情報共有

国際協力で運用される探査機・周回機では、複数機関の航法チームがそれぞれ独立に軌道決定を行い、その結果を突き合わせて整合性を確認する「クロスチェック」が定常的に行われます。たとえば火星探査における複数機関の周回機・着陸機運用や、国際宇宙ステーション(ISS)の軌道情報をNASAとロシアのロスコスモスの管制チームが共有する運用では、各機関が自前の軌道力学ソフトウェア(NASAのGMAT、JPLのMONTE、商用のAGI/Ansys STKなど、前々回で触れたMONTEもここに含まれます)を使っていても、ODMという共通の交換フォーマットを介することで、ソフトウェアの違いを気にせず軌道情報をやり取りできます。これは、あるチームがMONTEで計算した軌道を、別のチームがSTK上で読み込んで独自に検証する、といった機関・ツールをまたいだ相互検証を技術的に可能にしています。

商用衛星運用者間のデータ共有

静止軌道上の商用通信衛星は非常に密集した領域を共有しているため、事業者間の衝突回避情報共有が実務上重要です。複数の大手衛星通信事業者が加盟するSpace Data Association(SDA)は、加盟事業者間で軌道歴データを定常的に交換し、接近が予測される場合に運用者同士が直接連絡を取り合える仕組みを構築しています。標準化された軌道歴形式によってこうした交換が機械的に処理できることは、地球低軌道のメガコンステレーション(多数機からなる衛星群)が急増する近年、ますます重要性を増しています。LeoLabsやExoAnalytic Solutionsのような商用SSA事業者も、独自に取得した軌道情報を顧客である衛星運用者に配信する際、CCSDSの標準形式との親和性を意識したデータ提供を行っています。

演習問題

OEM・OPM・OMMのそれぞれについて、「コンジャンクション評価のために今後72時間の接近距離を評価したい」「軌道決定バッチ処理が終わった直後に、その瞬間のベスト推定状態を共同ミッションの相手機関へ即座に通知したい」「多数のデブリ物体をまとめて公開カタログとして配信し、利用者側でSGP4により各自伝播してもらいたい」という3つの状況にそれぞれどの形式が適するか、理由とともに答えてください。
本文中の座標系取り違えの見積もりでは、静止軌道( $r\approx 42{,}164\ \text{km}$ )でエポックから6時間後の取り違えを想定し $\Delta r\approx 59{,}600\ \text{km}$ という誤差を得ました。同じ考え方で、低軌道(高度約400 km、 $r\approx 6{,}771\ \text{km}$ )の衛星について、エポックから90分後(地球はその間に約22.5°自転する)の座標系取り違えによる誤差 $\Delta r$ を計算してください。静止軌道の場合と比べて誤差の絶対量がどう変わるか、また軌道半径に対する相対誤差がどう変わるかを論じてください。
Mars Climate Orbiterの事故では、力積の単位(lbf·sとN·s、換算係数約4.45)の取り違えが軌道計算の誤りにつながりました。もし仮に、ある探査機の状態ベクトルの位置成分がkm単位で記述されているファイルを、受信側のソフトウェアがm単位だと誤解して(すなわち実際の値を1000倍小さいものとして)読み込んでしまった場合、探査機の位置はどのように誤って解釈されるか、具体的な数値例(たとえば本文のOPM例にある X = 6678.140 [km] を用いて)を挙げて説明してください。
国際相互運用の回では、標準化がなければ相互運用協定のコストが機関数 $N$ の2乗のオーダーで増大することを見ました。もし各宇宙機関・各商用衛星運用者が、軌道情報の交換フォーマットをそれぞれ独自に定めていたとしたら、コンジャンクション評価のような「多数の機関・事業者が互いに物体の軌道を突き合わせる」業務にどのような支障が生じるか、 $O(N^2)$ の議論を踏まえて説明してください。

まとめと次回予告

この回では、前々回で学んだ軌道決定の計算結果——状態ベクトルとその共分散——を、機関やソフトウェアの垣根を越えて受け渡すためのCCSDS標準フォーマット群を見てきました。単一エポックのスナップショットを運ぶOPM、時系列のエフェメリスを運ぶOEM、平均軌道要素を運ぶOMMという3形式が、それぞれ異なる用途に対応して使い分けられていること、そして姿勢情報にも同じ思想でAPM/AEMが用意されていることを見ました。さらに、これらのメッセージが座標系・時刻系・単位を明示するメタデータをデータそのものと同じ重みで扱っている理由を、簡単な幾何学的見積もりと、Mars Climate Orbiterの事故という歴史的教訓から確認しました。実務では、コンジャンクション評価のためのCDM交換や、複数機関・複数ソフトウェア間の軌道クロスチェック、商用衛星運用者間の衝突回避データ共有など、この標準化がなければ成立しなかったであろう協力体制を支えています。

次回は、この回で扱った「軌道決定の結果」を運ぶODMとは対をなす存在として、軌道決定の入力、すなわち測距・ドップラーなどの生の追跡観測量そのものを標準形式で交換する**Tracking Data Message(TDM)**に軽く触れます。ODMが「答え」を機関間で共有するための形式だったのに対し、TDMは「問いを解くための材料」そのものを共有するための形式であり、両者を合わせて初めて、軌道決定という営みの入口から出口までが標準化された枠組みの中に収まることになります。

参考文献

CCSDS 502.0-B-3, Orbit Data Messages
CCSDS 504.0-B-1, Attitude Data Messages
CCSDS 508.0-B-1, Conjunction Data Message
CCSDS 500.0-G-4, Navigation Data — Definitions and Conventions (Green Book)
B. D. Tapley, B. E. Schutz, G. H. Born, Statistical Orbit Determination, Elsevier Academic Press
NASA/JPL, Mars Climate Orbiter Mishap Investigation Board Phase I Report, 1999
O. Montenbruck, E. Gill, Satellite Orbits: Models, Methods, and Applications, Springer