The Assembly, Integration and Verification (AIV) work package represents one of nine key elements that will make up the SKA1 Telescope. Whereas the other eight elements are tasked with designing key components of the SKA1 Telescope, the AIV element is tasked to perform all necessary planning to integrate these key components into a telescope system that meets the engineering (Level-1) requirements.
The SKA1 Telescope will consist of SKA1-mid, which will be located in South Africa, and SKA1-low, which will be located in Australia. SKA1-mid will consist out of up to 133 SKA1-mid dishes, plus a further 64 MeerKAT precursor dishes. The AIV work package therefore also includes the planning for integrating the MeerKAT Precursor into the SKA1-mid Telescope. SKA1-low will consist out of 512 SKA1-low Stations, which will include a total of approximately 125,000 individual low-frequency antennas.
The member organisations of the AIV Consortium are SKASA, CSIRO and ASTRON, with SKASA leading the consortium. All three member organisations have significant experience in building radio telescopes, and therefore have a vast amount of integration and verification know-how that is benefitting the AIV work package.
2016 SKA Engineering Meeting
This year’s Engineering Meeting was another great success. Face-to-face discussions with other consortia and with colleagues at the SKA Office are always productive and beneficial. The AIV Team participated in many of the meetings, but the following where particularly informative:
- Meeting with SaDT and DISH Consortia to discuss issues pertaining to the MeerKAT retro-fit (ECP-150006). Each MeerKAT Dish will be retro-fitted with an SKA1-mid Receiver and SKA1-mid Timing & Frequency Reference distribution system.
- Construction Dry-Run for SKA1-mid and SKA1-low. The objective of these workshops was to arrive at a plan and a schedule of how the project will arrive at the system installed in the System ITF and how the project will arrive at Array Assembly1.
Telescope Roll-Out Plan
Revision5 of the Roll-Out Plan for SKA1-mid and SKA1-low has been released. This revision includes major updates and incorporates all of the review comments received from the SKA Office and from Design Consortia. Feedback obtained at the SKA Engineering Meeting has also contributed significantly to this release. For each Array Assembly, a lot of detail has been added about the products and functions that make up that Array Assembly. The Array Assemblies are now very well defined, forming the basis for identifying all the dependencies that will be reflected in the Construction Schedule.
For both SKA1-mid and SKA1-low, all of the system-level functions have been allocated to one or more of the high-level roll-out milestones, namely:
- Integration Test Facility Qualification Event (ITF-QE)
- Array Assembly 1
- Array Assembly 2
- Array Assembly 3
- Array Assembly 4
Since each function is also related to one or more Level-1 (or Level-2) Requirement(s), as shown in the figure, this work provides Design Consortia with significantly more information regarding the required functionality for each of the Array Assemblies, including the System ITF.
From this revision onwards, no dates or timelines are specified in the Roll-Out Plans. The Construction Schedule is managed by the SKA Office and the Roll-Out Plans merely refer to this schedule. This ensures that all construction dates are maintained in one central location.
With the approval of ECP-160027, the scope of work of the AIV Consortium has been extended to include the verification planning of all Level-1 Requirements.
The Level-1 Requirements fall into two main categories:
- Those that are allocated to only one Element,
- Those that are allocated to more than one Element.
For those L1 Requirements that fall into the first category, it is assumed that there is no emergent behaviour at system level, and that these L1 Requirements are therefore fully described by their corresponding L2 Requirements of the respective Element. The system-level verification planning of this category of L1 Requirements consists of:
- Inspection of the Verification Plan at Element CDR.
- Inspection of the product contractor’s Acceptance Test Results at the time of product hand-over to the SKAO.
For those L1 Requirements that fall into the second category, it is assumed that there is emergent behaviour at system level, and the AIV Consortium is tasked to produce a Verification Plan for these L1 Requirements that will contain the following:
- A high-level description of how each of these L1 Requirements will be verified. These descriptions are not as detailed as a test procedure.
- At what level of system integration the verification will be performed (either the System ITF or one of the Array Assemblies).
- Identification of who is responsible for executing the verification. Generally, the SKAO will be responsible for all qualification testing and verification testing performed at the System ITF, and the AIV Contractor will be responsible for all verification testing performed on-site.
The Verification Model
The Telescope System verification activities are derived by developing the Verification Model shown in the figure below.
Starting with the Level-1 Requirements, which specify the Telescope System, Verification Requirements are developed, which outline how the Level-1 Requirements will be verified. Verification Events are identified, as well as Test Procedures, Test Configurations and Test Equipment.
Verification Requirements are a high-level description of the tests that are needed to verify the requirements. In themselves, they are not sufficiently detailed to be used as qualification or acceptance test procedures, but they represent the first step towards the development of detailed Test Procedures, Test Configurations and the identification of Test Equipment.
Experience with other radio telescopes has consistently shown that the roll-out activities and AIV work scope is often under-estimated, even at component level, and often causes delays in deployment, due to re-engineering and retrofitting of components. This may significantly increase the total cost of the system.
Many issues that are discovered during “downstream” integration and verification are the result of “upstream” neglect. Early in the project, during the design stage, science requirements need to be accurately translated to Element-level requirements, and interfaces between products need to be accurately defined.
Another major challenge is that the software/firmware dominated Elements (CSP, SDP and TM) need to deliver systems with basic functionality very soon after tenders have been awarded.