Processing Block definitions

This definition will continue to evolve over the first few years of construction, significantly and quickly in the earlier period.

What is needed at this point is sufficient elaboration in order to support System CDR de-risking activities, especially in these main areas:

1. Prototyping of the interfaces to the SDP, the basic Processing `Block interface;
2. The next step of using multiple PBs to model the planning of data processing. (SP-50 and SP-51).
3. Dealing with "out of band" processing (i.e. where context of the observing is no longer current).
4. Do we need to worry about "Observing Groups" (see SP-172) yet?

A first version of a Processing Block is required. This requires input from the SDP. What can also be considered is the relationship of the PB to the SB (separate entities?) and what information from the SB is required for use by the SDP (what is necessary? what is available elsewhere - from TMC?).  This document: https://docs.google.com/document/d/1phahPm1tVAPvP9glQVFQWWfHmJtEfIEVWDdAvXf2jhM/edit#heading=h.ry603i3q5w6o contains a useful discussion relating to the PB definition.

Lastly, some thought should be given to the data exchange and local persistence format of PBs.   Is this JSON?     The long term persistence (in the ODA) is a separate concern.

OLD TEXT

This task would be in support of ----SP-41---, SP-50  and SP-51. It will expand the current definition of a Scheduling Block in the Project Data Model to provide a simple but realistic version 1 that may be used in the evolutionary control prototype for section -----SP-41----, and to provide inputs to the planning tools in SP-50 and SP-51 and enable the creation of Processing Blocks that may be used for the sub-task of SP-51 that utilises the SDP planning interface. In order to do this an initial definition of PBs will also be developed. 

SoW Chapter 3.16