From 6d4dac4a21db74ae599fa7e97cd2e1cb1d22c5dd Mon Sep 17 00:00:00 2001 From: Jack Harper Date: Tue, 2 Jun 2026 09:13:32 +0100 Subject: [PATCH 1/3] adr for run metadata --- .../datastreaming/ADRs/007_run_metadata.md | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 doc/specific_iocs/datastreaming/ADRs/007_run_metadata.md diff --git a/doc/specific_iocs/datastreaming/ADRs/007_run_metadata.md b/doc/specific_iocs/datastreaming/ADRs/007_run_metadata.md new file mode 100644 index 000000000..ce3727e21 --- /dev/null +++ b/doc/specific_iocs/datastreaming/ADRs/007_run_metadata.md @@ -0,0 +1,24 @@ +# 7 - Run metadata + +## Status + +Accepted + +## Context + +In the ICP-based system, `ISISDAE` is responsible for serving PVs such as `TITLE` and `USERNAME`, which get fed into the ISISICP through asyn calls. + +This has historically meant that if any other data acquisition hardware needed to be integrated, other than a DAE2 or DAE3, whichever service responsible for controlling the hardware should also serve PVs for run metadata. + +`kafka_dae_control` was also started in this way, however as this is a distributed system it might make sense to split this functionality out into a soft IOC, which can handle the auto saving behaviour and so on. + +## Decision + +For both the ICP and streaming systems, we will pull out things like `TITLE` and `USERNAME`, and any other PVs which are not strictly related to the hardware, and put them in a soft IOC such as `INSTETC`. + +## Consequences + +- `kafka_dae_control` will get smaller in terms of responsibilities, which may make it easier to maintain +- If we need to write `kafka_dae_control_2` for whatever reason (ie. new streaming control boards with a different interface), its reponsibilities should be limited to just controlling the hardware and serving PVs to do so. +- Some extra effort will be required to add these PVs to `INSTETC` and modify the ICP to suit, as well as removing them from `kafka_dae_control` +- `kafka_dae_control` will rely on CA/PVA for these items. This is already the case for the list of blocks which is required to form a run start message. From d25f09cdf7f9cd90964fc786f9fde74db36a2534 Mon Sep 17 00:00:00 2001 From: Jack Harper Date: Tue, 2 Jun 2026 09:17:04 +0100 Subject: [PATCH 2/3] typo --- doc/specific_iocs/datastreaming/ADRs/007_run_metadata.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/specific_iocs/datastreaming/ADRs/007_run_metadata.md b/doc/specific_iocs/datastreaming/ADRs/007_run_metadata.md index ce3727e21..0bfa664ef 100644 --- a/doc/specific_iocs/datastreaming/ADRs/007_run_metadata.md +++ b/doc/specific_iocs/datastreaming/ADRs/007_run_metadata.md @@ -19,6 +19,6 @@ For both the ICP and streaming systems, we will pull out things like `TITLE` and ## Consequences - `kafka_dae_control` will get smaller in terms of responsibilities, which may make it easier to maintain -- If we need to write `kafka_dae_control_2` for whatever reason (ie. new streaming control boards with a different interface), its reponsibilities should be limited to just controlling the hardware and serving PVs to do so. +- If we need to write `kafka_dae_control_2` for whatever reason (ie. new streaming control boards with a different interface), its responsibilities should be limited to just controlling the hardware and serving PVs to do so. - Some extra effort will be required to add these PVs to `INSTETC` and modify the ICP to suit, as well as removing them from `kafka_dae_control` - `kafka_dae_control` will rely on CA/PVA for these items. This is already the case for the list of blocks which is required to form a run start message. From 8dca7a60b58bec33bcc2b96b39f698dfa806e002 Mon Sep 17 00:00:00 2001 From: Jack Harper Date: Tue, 2 Jun 2026 14:13:44 +0100 Subject: [PATCH 3/3] list PVs --- .../datastreaming/ADRs/007_run_metadata.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/doc/specific_iocs/datastreaming/ADRs/007_run_metadata.md b/doc/specific_iocs/datastreaming/ADRs/007_run_metadata.md index 0bfa664ef..cd1a7c8ff 100644 --- a/doc/specific_iocs/datastreaming/ADRs/007_run_metadata.md +++ b/doc/specific_iocs/datastreaming/ADRs/007_run_metadata.md @@ -14,7 +14,16 @@ This has historically meant that if any other data acquisition hardware needed t ## Decision -For both the ICP and streaming systems, we will pull out things like `TITLE` and `USERNAME`, and any other PVs which are not strictly related to the hardware, and put them in a soft IOC such as `INSTETC`. +For both the ICP and streaming systems, we will pull out PVs which are not strictly related to the hardware, and put them in a soft IOC such as `INSTETC`. + +These PVs are: +- `TITLE` +- `_USERNAME` +- `RBNUMBER` +- `ISISCYCLE` +- `ISMUON` +- `INSTNAME` +- `WDTITLE` / `WDUSERS` ## Consequences @@ -22,3 +31,4 @@ For both the ICP and streaming systems, we will pull out things like `TITLE` and - If we need to write `kafka_dae_control_2` for whatever reason (ie. new streaming control boards with a different interface), its responsibilities should be limited to just controlling the hardware and serving PVs to do so. - Some extra effort will be required to add these PVs to `INSTETC` and modify the ICP to suit, as well as removing them from `kafka_dae_control` - `kafka_dae_control` will rely on CA/PVA for these items. This is already the case for the list of blocks which is required to form a run start message. +- `kafka_dae_control` will keep `RUNNUMBER` for now but we may consider moving this out at some point when it becomes clearer how multi-detector setups will deal with run numbers.