Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Interactive alarm editing proposal

オープン
  • 何か問題がありますか？
#3,920 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
活発
技術スタック
java, kafka
領域
frontend

調査の方向性

Start by reviewing the existing Phoebus alarm tree tools and the prototype video linked in the issue; the payload does not name source files or tests. Choose one specific improvement to scope before investigating its implementation, and define completion against that improvement, since the issue proposes several changes and leaves them open for discussion.

索引モデルが issue の本文から書いたものです。

説明

codathon discussion

Overview

Currently, the alarm configuration can be edited either by modifying the XML directly or using the tools in Phoebus (the move/duplicate/rename tools in the alarm tree, the configuration menu for alarms/components, and the 'Add PVs to alarm system' button).

At ISIS we are migrating our alarms from valarm to Phoebus. I am writing a conversion script to get us to a good starting point, but we expect a lot of manual tweaking will be needed potentially including frequent large changes like moving groups of alarms to different components. Having an interactive way to do this would be very helpful for us.

Possible improvements

The alarm tree could be improved as follows:

  • Search bar
  • Drag/drop
  • Copy/cut/paste
  • Allow component/alarm settings to be displayed on the right side of the PV tree screen rather than opening in a separate window
  • Keybinds (ctrl-x, ctrl-c, ctr-v, delete)
  • Change the 'Move PV' screen so that it does not create a new Kafka connection each time - currently we need to wait several seconds to move a PV due to this
  • Remove the 'rename item' context menu button and instead add it to the configuration screen

Mirrored alarms

Another possible change which should probably not be implemented but still merits discussion is to allow alarms to appear in more than one component. The reasoning for this is that some alarms logically are split across components. For example, an alarm which is part of a cooling system spanning multiple components could appear in those components and also in a 'cooling system' component. This would not change anything in the alarm table. The obvious problems are that

  • this might lead to situations where an alarm is unintentionally disabled. To continue the example, the cooling system is still running, but one of the components it covers is disabled. Since the disabled component contains the cooling system alarm, this leads to a cooling system alarm being disabled. This isn't necessarily obvious behaviour and operators might not be aware that they have just disabled an alarm which is part of another system.
  • this introduces additional complexity and ambiguity in the UI - e.g. when an alarm is duplicated should the new alarm be mirrored to the old one so any configuration changes apply across both? A visual indicator would also be needed so it is possible to tell that an alarm appears in several locations. (And so on)
  • unlike the other proposed improvements, this would most likely require non-trivial architectural changes to the alarm server

Still, this might be a good starting point for a 'mode switching' system which allows components of an accelerator to be easily disabled without having to maintain an untenable number of mode configurations for each config. For example, at ISIS there are some components which are usually only run for testing during startup. Putting aside the above issues for a moment, a component could be created which contains all of these alarms, and when they are no longer being used an operator could simple right click -> disable all on said component. Mirroring would allow these alarms to exist both under this 'startup testing' component and also under separate components which indicate their physical position in the machine.

Prototype

I have created a prototype which is essentially a more interactive version of the alarm tree to test some ideas. It is slightly rough around the edges and has some bugs but does update the alarm configuration live in Kafka. Here is a video of it so far:

https://github.com/user-attachments/assets/133c50ac-a7e0-41ea-b56e-c757522971ac

As this functionality is needed at ISIS anyway, I plan to implement at least some of the proposed improvements in due course but wanted to put this out there first to gather input. If something useful comes out of it we'd like to contribute.

主要言語
Java
スター
130
フォーク
132
平均マージ
3日 1時間
マージ済み PR（30日）
24

環境構築

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ControlSystemStudio/phoebus のほかの issue

ControlSystemStudio/phoebus の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。