Pipeline lifecycle and interface
An EDD pipeline combines a KATCP control server, a container and Ansible role, and the processing program or device it manages. All pipelines implement the same lifecycle even when their internal processing is entirely different.
Pipeline flavours
- Measuring pipelines
These pipelines act on individual scans. After capture starts they enter
readyand use measurement prepare, start, and stop transitions for each scan. Writers and pulsar processing are typical examples.- Streaming pipelines
These pipelines run continuously across scan boundaries. After capture starts they enter
streaming. Measurement commands may update metadata or be acknowledged, but do not leave that state. A correlator-beamformer is a typical example.
The core can infer the flavour from overridden measurement methods, but new
pipelines should pass an explicit PipelineFlavor to make their behaviour
unambiguous.
State model
Stable EDD pipeline states. Short-lived transitional states are omitted.
idleThe server is running and accepts configuration changes.
configuredLong-lived resources, processes, and stream descriptions are configured.
readyA measuring pipeline is capturing and can prepare a scan.
setScan metadata has been accepted and the pipeline can start measuring.
measuringThe pipeline is processing the current scan.
streamingA streaming pipeline is processing continuously.
inactiveThe pipeline was disabled for the current scan by
measurement_prepare_default.activeor the scan configuration.stalledThe current scan cannot be processed, but a later scan may recover.
errorAn operational transition failed. Deconfigure is the normal recovery path.
panicDeconfiguration failed and manual cleanup may be required.
The implementation also reports transitional states such as configuring,
capture-starting, measurement-preparing, measurement-starting,
measurement-stopping, deactivating, and deconfiguring. These are
not safe points from which to issue another lifecycle command.
Common KATCP requests
Request |
Valid source state |
Effect |
|---|---|---|
|
|
Merge a partial configuration without changing state. Unknown keys are rejected; type changes currently produce warnings rather than complete schema validation. |
|
|
Optionally merge configuration, allocate resources, and enter
|
|
|
Activate ingest and enter |
|
|
Apply scan metadata and enter |
|
|
Begin scan processing and enter |
|
|
Finish the scan and return to |
|
Any state |
Stop pipeline resources and return to |
?capture-stop remains available for compatibility but is ignored by the
current core state model. Use ?deconfigure to stop capture and release
resources.
Common configuration
The base class adds these keys to every pipeline configuration:
idandtypeUnique product identifier and pipeline type.
input_data_streamsandoutput_data_streamsStream descriptors. Inputs may use
sourcereferences that the Master Controller resolves during configure.data_storeRedis host and port used for registration and shared state.
measurement_prepare_default.activeDefault scan activation flag. Setting it to false places a measuring pipeline in
inactivefor a scan.ignore_pipeline_errorsControls how the Master Controller treats a product error. Use only when an observing mode is deliberately able to continue without that product.
Developer responsibilities
A pipeline implementation must:
release every resource acquired during configure when deconfigure is called, including after partial failure;
validate scientific and hardware constraints not covered by the base class;
declare final output stream metadata before downstream configuration;
expose actionable status, throughput, buffer, and error sensors;
write all application logs to standard output;
register generated files so measurement stop can report them; and
supply unit, lifecycle, and provision tests.
See Developing EDD pipelines and plugins for a current implementation template.