スクエアキロメートルアレ観測所のソフトウェア内で

スクエアキロメートルアレイ天文台（SKAO）の観測科学運用（OSO）サブシステムは、観測を管理するためにさまざまなツールを使ってる。主な役割は、科学的な作業と望遠鏡をつなげることで、すべてがスムーズに動くようにし、使いやすくすることだ。この文章では、主要な工事段階に近づく中での天文台ソフトウェアの現状、現代技術を使ったツールの構築方法、開発中の課題について話すよ。

#SKAOの概要

SKAOは、イギリスのジョドレルバンクにある本部、南アフリカにあるSKA-Mid、オーストラリアにあるSKA-Lowの3つの場所で2つの望遠鏡を運営してる。OSOは観測所を動かすソフトウェアの一部で、天文学者や望遠鏡オペレーター、SKAOのスタッフが使うウェブベースのツールで構成されてて、作業しやすいインターフェースがある。OSOは観測の異なる段階に対して半自動化されたシステムを作り、ユーザーと生成された科学データをつなぐ。

今年は調整活動が始まる年で、初期のディッシュを使ってシステム全体のテストを行う予定だ。いくつかのOSOツールはこの調整活動中に利用されるけど、他のツールは後の運用ニーズのために設計されてる。

3つのソフトウェアチームがOSOの開発に取り組んでおり、2つはイギリス、1つはインドにある。彼らはSAFeというプロジェクト管理方法を使って密に協力し、すべての関連プロジェクトに貢献してる。各チームはOSOの多様なニーズに対応するための専門分野を持ってるよ。

#機能的および非機能的要件

SKAOのような大規模な天文台には、多くの複雑なニーズが建設前に把握されてる。観測提案の作成や確認といった基本的な能力に加えて、OSOは異なるプロジェクト間でリソースを共有できるようにし、望遠鏡から同時に複数の観測ができるようにしなきゃならない。ツールはこれらのアイデアをシンプルに提示し、天文学者がリクエストを望遠鏡に送る前に素早く理解して定義できるようにしなきゃいけない。

OSOのユーザーには、天文学者、提案審査者、SKAOスタッフ、望遠鏡オペレーターがいる。機能的なニーズに加え、いくつかの品質面も重要だ。ユーザー側には、反応が早く、使いやすい現代的なインターフェースが期待されてる。SKAOはアクセシビリティを重視していて、ウェブインターフェース作成時にも考慮されてる。信頼性とセキュリティは、望遠鏡制御システムとつながるツールにとって特に重要だ。

#ソフトウェアの構造

観測プロセスは、提案の準備から観測の実行と追跡まで複数のステップがある。これらのステップは、数ヶ月前から実際の観測中のリアルタイムコマンドまで、異なる時間軸で行われる。各ステップは、後で使用するためのデータ記録を作成する必要があり、次のステップを開始するには前のステップの情報が必要だ。これを管理するために、OSOは共有データアーキテクチャを使用していて、各アプリケーションが中央データベースにデータを読み書きする仕組みだ。

アプリケーション同士は直接通信せず、中央に保存されたデータにアクセスして修正する。これにより、同じデータモデルを共有しながらも、アプリケーションを独立して開発・テストできる。こうした設計は、各ツールが同じシステム内で独立に進化できる柔軟性を提供する。

#技術選択

OSOツールは、現代の技術スタックを使って構築されてる。ほとんどのアプリケーションはウェブベースで、Kubernetes上で動くコンテナにパッケージ化されてて、簡単にデプロイできる。機能はAPIを通じて公開され、ユーザーはグラフィカルユーザーインターフェースやコマンドラインインターフェースを介してやりとりする。

アプリケーションのフロントエンドは、柔軟でユーザーフレンドリーなデザインを作る能力があるTypescriptとReactを使って開発されてる。バックエンドサービスにはPythonが使われて、SKAOの好みに合わせている。APIはOpenAPI仕様を使って定義されてて、信頼性を確保し、フロントとバックエンド間の明確な契約を提供してる。

強力な継続的インテグレーションとデリバリーシステムが整っていて、ソフトウェアの新しいバージョンが正しくテストされ、文書化されることを保証してる。各アプリケーションは統合テストを受けて、システムの他の部分と正常に動作することを確認してる。

#データ構造と管理

SKAプロジェクトデータモデル（PDM）は、OSOアプリケーションで使用されるデータの基盤となるフレームワークだ。Pythonライブラリとして公開されていて、すべてのOSOツールに含まれてる。データ処理時の安全性と検証を提供するために、このモデル内でPydanticが使われてる。このモデルからOpenAPIスキーマが作成され、すべてのデータモデルに対して単一の真実のソースが確保される。

データモデルの主要な構成要素には以下が含まれる：

• 提案: 天文学者からの観測や観測セットを定義するもので、提出に必要なすべての詳細が含まれる。

• プロジェクト: 受け入れられた提案から作成され、定義や観測が含まれる。

• スケジューリングブロック定義（SBDefinition）: 観測を実行するための指示が含まれる、最小単位のスケジューリングで、ユーザーによって変更可能。

• スケジューリングブロックインスタンス（SB Instance）: 実行中の特定のバージョンのSBDefinitionの記録。

• 実行ブロック: SBInstanceの実行中に望遠鏡に送られたコマンドと受け取った応答が含まれる。

OSOデータアーカイブ（ODA）は、この構造のすべてのデータの中央ストレージとして機能し、内部プロセスをサポートし、生成された科学データへの接続を可能にする。

#OSOのツール

OSOで利用可能な主なツールには以下が含まれる：

• 提案処理ツール（PHT）: 観測提案を管理し、天文学者が観測を提出できるようにし、スタッフがそれをレビューできる。

• 観測設計ツール（ODT）: スタッフが提案からプロジェクトとSBDefinitionsを作成するのを助ける。

• プロジェクト追跡ツール（PTT）: スタッフがプロジェクトの状態を監視および更新するために使用される。

すべてのツールは似た構造を持ち、Reactで構築されていて、一貫した外観と感触を確保している。バックエンドサービスとはRESTful APIを介して通信する。

#計画とスケジューリング

観測計画ツール（OPT）は、さまざまな要因に基づいて観測のランキングリストを作成する。このリストは定期的に更新され、観測スケジューリングツール（OST）のある望遠鏡サイトに送られ、現在の条件に対して評価される。OSTは最適な観測を選択し、観測実行ツール（OET）にコマンドを送ってタスクを実行させる。

初期段階では、オペレーターが手動で実行する観測を選択する。ただし、完全運用状態では、ワークフローはほとんど自動化されると期待されていて、いくつかの重要な領域での人間の監視も可能だ。

#観測の実行

観測実行ツール（OET）は、望遠鏡の観測の実行を管理する。オペレーターに対して、実行中の観測を開始、停止、監視する能力を提供する。OETはOSTと通信し、コマンドを受け取って必要に応じて実行する。

OETはスクリプトを使用してSBInstanceデータを望遠鏡のコマンドに変換する。このアプローチにより、システム全体を停止することなく、スクリプトの更新が可能になる。

#感度計算機

もう一つのツールとして感度計算機が開発されていて、天文学者に観測の感度についての情報を提供する。このツールは一般に公開されていて、提案設計を支援し、他のデータ構造とは独立して動作する。

#結論

天文学のための現代的なアプリケーションの開発を通じて、チームはUIデザインとサービスの責任について貴重な教訓を学んだ。OpenAPI仕様を使用することで、開発者とステークホルダー間の明確なコミュニケーションが促進された。大規模プロジェクトには予想通りの課題があったけど、得られた知識が今後の改善に役立つだろう。

SKAOのソフトウェアは、高品質なパフォーマンスを提供するために順調に進んでいる。天文台が運用能力に近づく中で、ユーザー体験の向上と科学コミュニティのニーズに応える機能の拡張に焦点を当て続ける。