Table of Contents
Previous Chapter
Table of Contents
Previous Chapter
This section describes the preliminary design of the ACIS Back End's FEP (Front End Processor) Management software. This software is responsible for configuring science runs, starting the runs, and for acquiring, processing, and sending data from the runs.
Figure 14 provides a coarse overview of science processing, where the numbers indicate the overall sequence of events for a science run.
FIGURE 14. Science Processing Overview
When performing science operations, the system is treated as a pipeline. Images are produced by the CCDs, which are then, via the DEA, fed into the FEPs. The FEP hardware provides the capability to accept or ignore a complete exposure. If an exposure is accepted, it is read into the FEP's image buffer. The FEP software then scans the image looking for events. As events are found, the FEP software extracts the relevant event information and forwards it to the BEP. The BEP accepts event information from each of the active FEPs, keeping the different CCD information separate. The BEP then filters a given CCD's events, packs the accepted events into a data packet, and posts the data packet to be telemetered. As each exposure completes, the BEP forms an exposure record for each of the FEPs, and enqueues the formed packets to be telemetered.
In order to synchronize the FEP exposure processing, each FEP queries the BEP before accepting or rejecting data from the next exposure. Once all of the active FEPs have reported, the BEP notifies them all that they may proceed with the next exposure.
If the telemetry queue becomes backlogged to the point where the BEP stops reading FEP data, and one or more of the FEP buffers fill, the FEPs will wait (i.e. block) until some room becomes available. If the condition persists, the blocked FEP hardware will drop one or more subsequent exposures. Since one or more of the FEPs won't be bothering the BEP about proceeding to the next exposure, the BEP will stop responding to other FEP requests to proceed, causing all of the remaining FEPs to block. When this happens, all of the FEPs drop data from the same exposures. The FEP software is responsible for keeping track of which exposures are dropped by numbering each exposure, regardless of whether or not it is accepted by the hardware. Once the telemetry queue has room, the BEP starts reading the FEP data again, the jammed FEP(s) finish the suspended exposure and query the BEP to proceed. The BEP finally responds to the queries, and the event processing resumes. Since the FEPs are numbering each exposure whether it is processed or not, the dropped exposures will correspond to missing exposure numbers in the telemetry stream.
All parameters which select and control a Science Run are supplied by ROM or parameter blocks loaded by command into the Back End Processor. The Back End software encapsulates the top level representation of parameter blocks using a "Parameter Block" class. Different types of parameter blocks "inherit" from this top level definition by providing additional operations which are specific to the particular type of block being defined. Table 32 lists the operations provided by the top-level Parameter Block definition.
TABLE 32. `Parameter Block'Operations
---------------------------------------------------------------------------------------------------- Function Inputs Outputs---------------------------------------------------------------------------------------------------- Initialize none Marks the block as "unused" Get Block Id none Returns the "block id" of the Parameter Block Check CRC none Computes the block's CRC and compares it with the stored CRC. If the values are different, this function returns an error. Get Length none The length of the parameter block Get Parameter none The Parameter Block Identifier used by the ground to Block Identifier associate the block with the resulting science data. Copy to Buffer Address of destination Fills the specified destination buffer with the contents buffer. of the parameter block's data. The copied data has the same format as the data portion of the Command Packet used to load the block. Load from Com Address of Command none mand Packet Packet containing the new block contents ----------------------------------------------------------------------------------------------------
All parameter blocks are maintained by the Back End using type-specific Parameter Block Lists. These lists are implemented as arrays of "Parameter Block" classes, where the parameter's "block id" serves as the index into the array, and the type of block selects which array to use. The Back End software encapsulates this representation using a generic Parameter Block List class. This class serves to standardize the interface to the block-specific lists. Table 33 lists the operations provided by this class.
TABLE 33. `Parameter Block List'Operations
-------------------------------------------------------------------------------------------- Function Inputs Outputs-------------------------------------------------------------------------------------------- Initialize none Re-loads ROM blocks and marks remaining blocks as "unused" Check Blocks none Computes the CRC of all used blocks and flags any which have been corrupted. Replace Block Command Packet containing Overwrites a block with the new parameters Parameter Block id and con specified in the Command Packet. tents Get Block Block Id Address of the parameter block, or an error code if the block is unused or has an invalid CRC. --------------------------------------------------------------------------------------------
The Back End software manages an overall science run using the operations provided by a "Science Run" class. This class is responsible for fetching the parameters for a science run, dumping the parameters into the telemetry stream, and for dispatching control to the selected "Science Mode." The operations provided by a "Science Run" are listed in Table 34.
TABLE 34. `Science Run'Operations
----------------------------------------- Function Inputs Outputs----------------------------------------- Initialize none none Execute Run Parameter Block Id none Shutdown Run Parameter Block Id none -----------------------------------------
The Back End software controls a science run using a type of "Science Mode." A "Science Mode" class defines the generic properties of all science modes. Each specific type of mode inherits from this base class, and supplies any mode specific properties, operations, or implementations. Table 35 lists the operations provided by all "Science Modes."
TABLE 35. `Science Mode'Operations
--------------------------------------------------------------------------------------------- Function Inputs Outputs--------------------------------------------------------------------------------------------- Initialize none none Setup Address of the Parameter Block to Sets up the DEA, the FEP, and any internal use for the run data filtering and processing information Start Run none Start the DEA and FEPs. This establishes the start time of the run. Process Expo none Acquire and process one exposure from one sure (or more TBD) of the FEPs. Shutdown Run none Shutdown the DEA and FEPs and close out any pending data processing. Check Run none Perform post-run integrity checks and pro duce a final science run report. ---------------------------------------------------------------------------------------------
A given "Science Mode" uses a PRAM synthesizer class to generate the PRAM sequence used to clock the CCDs for a given mode. Each type of clocking mode defines its own synthesizer class, but in order to present a simple and consistent interface, these classes are all types of a generic "PRAM Synthesizer" class. Table 36 lists the general operations provided by this class.
TABLE 36. `PRAM Synthesizer'Operations
-------------------------------------------------------------------------------- Function Inputs Outputs-------------------------------------------------------------------------------- Initialize none none Generate CCD List Generates a PRAM sequence given the Clocking Parameters to use specified parameters, and loads the sequence into the DEA subsections associ ated with the specified CCDs. Check CCD List Generates a PRAM sequence given the Clocking Parameters to use specified parameters, and compares the sequence with that loaded in the DEA sub sections associated with the specified CCDs. --------------------------------------------------------------------------------
All event data produced by the Front End processors consist of a collection of pixel values and pixel bias information. Different types of data produce different numbers of pixels with different dimensions, but the overall property of the data is still a collection of pixels. For this reason, the Back End represents all event data as some subclass of a "Pixel Array" class. Table 37 lists the operations provided by this generic data representation.
TABLE 37. `Pixel Array'Operations
-------------------------------------------------------------------------------------------------- Function Inputs Outputs-------------------------------------------------------------------------------------------------- Initialize none none Get Position none Returns the row and column of the bottom left- most pixel in the array. Get Width none Returns the width of the array in pixels. Get Height none Returns the height of the array in pixels. Get Pixel Pulse Pixel Row and Column, Returns the raw pulse-height of the pixel addressed Height relative to bottom-left by the specified location. pixel in the array. Get Pixel Bias Pixel Row and Column, Returns the bias associated with the pixel relative to bottom-left addressed by the specified location. pixel in the array. Pack to Buffer Address of the destina Bit-packs the pixel data into the specified buffer. tion buffer. The 12-bit raw pixel pulse-heights are bit-packed Bit-index into the first into the buffer, starting with the bottom pixel row word of the destination of the Pixel Array and moving left to right and then buffer. up to the next row. The first bit written to in the Max. Length of the destination buffer is specified by the Bit-Index buffer. argument to the function. This allows the Pixel Array data to be bit-packed along with other infor mation into a single destination buffer. --------------------------------------------------------------------------------------------------
The Back End software uses a sub-class of "Pixel Array" to represent event data produced by the Front End processors. This is known as the "Event Data" class. This class adds operations which are helpful for event selection and processing, but are too inefficient or inappropriate for some forms handled by the more general "Pixel Array" data representation. Table 38 lists these additional operations.
TABLE 38. `Event Data'Operations
---------------------------------------------------------------- Function Inputs Outputs---------------------------------------------------------------- Get Event Amplitude none Returns the total corrected pulse- height of the event. Get Event Grade Code none Returns the "Grade" code of the event. ----------------------------------------------------------------
In order to maintain data processing throughput, the Back End software processes event data in collections, known as "Data Platoons." A "platoon" is a traffic term referring to a package or group of items. The Back End software acquires data from the Front Ends one "platoon" at a time, and then processes the data in the platoon until it is finally stored into the telemetry stream. In practice, each type of event representation uses a corresponding platoon subtype. These subtypes, however, are derived from a common base class. Table 39 lists the operations provided by this base class.
TABLE 39. `Data Platoon'Operations
--------------------------------------------------------------------------------------------- Function Inputs Outputs--------------------------------------------------------------------------------------------- Get CCD Id none Returns which CCD produced this platoon of data. Get Exposure Id none Returns the exposure, within the science run, which produced the data. Get Number of Elements none Returns the total number of "Pixel Array" elements contained in the platoon. Get Element index Returns a reference to the indexed data element. ---------------------------------------------------------------------------------------------
The Back End software provides the capability to filter Front End pixel data and event data based on the various properties of this data. The Back End defines a general "Data Filter" class. Table 40 lists the common operations provided by all Back End filters.
TABLE 40. `Data Filter'Operations
--------------------------------------------------------------------------------------------------------- Function Inputs Outputs--------------------------------------------------------------------------------------------------------- Initialize none none Reset Counters none Clears the filter's internal data acceptance and rejection counters Get Reject Count none Returns the current value of the filter's data rejection counter. Get Acceptance none Returns the current value of the filter's accep Count tance counter. A subclass-specific Address of the specific sub Returns whether or not to telemeter the passed Filter operation type of "Pixel Array" handled data. If the data is to be rejected, it increments by the filter its internal rejection counter. If the data is to be accepted, it increments the internal accep tance counter. ---------------------------------------------------------------------------------------------------------
Each subclass of "Data Filter" define its own "filter" function. Since each filter depends on data-specific properties, the declaration and implementation of the "Filter" operation is left up to the various sub-classes.
The Back End software uses a "Pixel Window Filter" class to select or reject raw data, or event data which falls into a specific region of the CCD. A "Pixel Window Filter" class is a subclass of "Data Filter." It only uses the common features of the class "Pixel Array," and can, therefore, process any subtype of "Pixel Array." Table 41 lists the operations provided by this filter.
TABLE 41. `Pixel Window Filter'Operation
----------------------------------------------------------------------------------------- Function Inputs Outputs----------------------------------------------------------------------------------------- Set Window Bottom Row none Bounding Box Left Column Pixel Width Pixel Height Filter Address of a "Pixel Array" or some Returns "reject" if the bounding box sub-type of "Pixel Array" of the window does not intersect the Pixel Array. Returns "accept" if they do intersect -----------------------------------------------------------------------------------------
The Back End software uses an "Event Amplitude Filter" class to select events whose amplitude are within a given range. An "Event Amplitude Filter" class is a subclass of "Data Filter." It uses the features of the class "Event Data," and can, therefore, process only subtypes of "Event Data." Table 42 lists the operations provided by this filter.
TABLE 42. `Event Amplitude Filter'Operation
---------------------------------------------------------------------------------------------- Function Inputs Outputs---------------------------------------------------------------------------------------------- Set Amplitude Lower Amplitude Boundary none Range Upper Amplitude Boundary Filter Address of an "Event Data" element or Returns "reject" if the amplitude of some sub-type of "Event Data" the event is less than the configured "Lower Boundary" or greater than the "Upper Boundary." ----------------------------------------------------------------------------------------------
The Back End software uses an "Event Grade Filter" class to select events whose "Grade" is in an acceptance list. An "Event Grade Filter" class is a subclass of "Data Filter." It uses the features of the class "Event Data," and can, therefore, process only subtypes of "Event Data." Table 43 lists the operations provided by this filter.
TABLE 43. `Event Data Filter'Operation
------------------------------------------------------------------------------------------------- Function Inputs Outputs------------------------------------------------------------------------------------------------- Set Grade Bitmap Address of a 256 bit-array, indicating none which Grade Codes to accept. Filter Address of an Event Data" element or Returns "reject" if the event's grade some sub-type of "Event Data" isn't in the acceptance bit-map. -------------------------------------------------------------------------------------------------
The Back End software manages all science telemetry buffering using a "Science Telemetry Buffer Pool." This pool contains a set of "Science Telemetry Packets," which are a subclass of "Telemetry Packet Buffer" and inherit the properties of that class. Each type of telemetry packet used by the science processing section comes from this pool. These types of packets use equally sized buffers, which are each large enough to contain the maximum packet length used by the science system. As exposures are acquired and their data are filtered, the "Science Mode" attempts to allocate a telemetry buffer for the data, and process the data directly into the buffer. Once the buffer is filled, it is posted to the "Telemetry Manager" for transfer out of ACIS. Once the "Telemetry Manager" is done with the buffer, it "deletes" the buffer, which effectively returns it to the science telemetry pool.
The Back End software uses a type of "Exposure Data" telemetry packet subclass to pack and telemeter pixel array data. Different types of science data define subclasses of this top level class. This class provides the operations listed in Table 44.
TABLE 44. `Exposure Data'Operations
------------------------------------------------------------------------------------------------- Function Inputs Outputs------------------------------------------------------------------------------------------------- Initialize Exposure Id none Get Max. Length none The maximum length of its data buffer. Get Available Space none The amount of space remaining in its data buffer Subclass specific "Add Address of particular subclass of "Pixel none Data" function Array" to process and pack into the buffer -------------------------------------------------------------------------------------------------
Each subclass of "Exposure Data" defines its own "Add Data" function. Since each filter depends on data-specific properties, the declaration and implementation of the "Add Data" operation is left up to the various sub-classes.
The Back End software uses a type of "Exposure Report" telemetry packet subclass to telemeter exposure-specific information (such as overclock levels, etc.). Different types of processing modes define subclasses of this top level class. This class provides the operations listed in Table 45.
TABLE 45. `Exposure Report'Operations
----------------------------------------------------------------------- Function Inputs Outputs----------------------------------------------------------------------- Initialize Science Run Start Time none Parameter Block Identifier Exposure Id Set Number of Elements Number of items sent in the "Exposure none Data" associated with the report. Set Bias Hits Total number of Bias Map parity check none failures since the start of the run. -----------------------------------------------------------------------
Once a Science Run has ended, the "Science Run" class sets up a "Run Report." A "Run Report" is a subclass of a "Science Telemetry Packet." It then proceeds to perform integrity checks on the key resources used during the run, and fills in the report. A "Run Report" supplies the operations listed by Table 46.
TABLE 46. `Run Report'Operations
-------------------------------------------------------------------------------------------- Function Inputs Outputs-------------------------------------------------------------------------------------------- Initialize Science Run Start Time none Identifier of the Parameter Block used to configure the run Set Exposure Count Number of exposures produced by the run none Set Bias Hits Total number of Bias Map parity check failures since the start none of the run. Set DEA Report The results of the DEA integrity checks none (TBD) Set FEP Report The results of the FEP integrity checks none (TBD) Set BEP Report The results of the local Back End data structure integrity none (TBD) checks --------------------------------------------------------------------------------------------
In order to send bias map information from each of the active CCDs, the software uses a "Bias Thief" class. This class actively acquires the bias values from the FEPs and compresses and telemeters the acquired values, as telemetry resources permit.
TABLE 47. `Bias Telemetry'Operations
--------------------------------------------------------
Function Inputs Outputs
--------------------------------------------------------
Start Bias Telemetry List of active FEPs none
Location of each bias map
Bias Map Row Width
Number of Bias Map rows
Stop Bias Telemetry none none
--------------------------------------------------------
Next Chapter