Recent news


At the end of October the SDP Consortium submitted its full document set for Critical Design Review. (These can be found at together with a large number of supporting memos ( and Table 1 below shows the documents in three main categories: those associated with software and hardware architecture; those explaining the supporting prototyping work that has been undertaken in support of the architecture, and finally those associated with system engineering (SE) and programmatics aspects (e.g. specifications for how SDP interfaces with the wider telescope systems and how components will be constructed). The documents will receive observations from a panel of reviewers up until the end of December. Responses to the observations and scenarios to ‘test’ the architecture will then be discussed at a review meeting from 15th to 18th January 2019 at Jodrell Bank.

After many years of effort, on 31st October 2018, the SDP Consortium submitted its design documentation for Critical Design Review (CDR). The SDP element already went through a pre-CDR review in June which included an Architecture Tradeoff Anaysis Method (ATAM) to identify risks and gaps with the architecture and examined the readiness of the System Engineering artefacts.


Since the last eNews submission in April 2018, the SDP Consortium successfully submitted a documentation pack of roughly 30 documents for its Pre-CDR, M20, milestone to the SKAO. The documentation pack included key Systems Engineering documents, Interface Control Documents (ICDs) and an updated snapshot of the latest SDP Architecture views since the M19 submission and review in November 2017.

In late June, a two-step review process was undertaken between SDP Consortium representatives and the SKAO M20 review panel. The first step was a documentation review process where the objective was to understand and assess the suitability and risks associated with the SDP design before entering the CDR review process. The second step was a face to face meeting which first analysed the suitability of SDP software architecture to meet the needs of its stakeholders, conducted using the SEI ATAM (Architecture Trade-Off Analysis Method) process and based on scenarios generated previously and then discussed observations made against the documentation pack in the first step.