SDP Interface Identification

Slides:



Advertisements
Similar presentations
Component Patterns – Architecture and Applications with EJB copyright © 2001, MATHEMA AG Component Patterns Architecture and Applications with EJB JavaForum.
Advertisements

1 Building with Assurance CSSE 490 Computer Security Mark Ardis, Rose-Hulman Institute May 10, 2004.
LSU 10/09/2007System Design1 Project Management Unit #2.
Chapter 2 TCP/ IP PROTOCOL STACK. TCP/IP Protocol Suite Describes a set of general design guidelines and implementations of specific networking protocols.
SKA Pre Construction Phase Infrastructure Tracy Cheetham Carel van der Merwe General Manager: Infra & Site OpsInfrastructure System Engineer
Hunt for Molecules, Paris, 2005-Sep-20 Software Development for ALMA Robert LUCAS IRAM Grenoble France.
CPIS 357 Software Quality & Testing
Protocol Architectures. Simple Protocol Architecture Not an actual architecture, but a model for how they work Similar to “pseudocode,” used for teaching.
1. 2 Purpose of This Presentation ◆ To explain how spacecraft can be virtualized by using a standard modeling method; ◆ To introduce the basic concept.
Guidelines for the Development and Maintenance of RTF- Approved Measure Savings Estimates December 7, 2010 Regional Technical Forum Presented by: Michael.
An Introduction to Software Architecture
SAMANVITHA RAMAYANAM 18 TH FEBRUARY 2010 CPE 691 LAYERED APPLICATION.
EOVSA Data and Database System Gordon Hurford and Jim McTiernan EOVSA Prototype Readiness Review 24-Sept-2012.
Doug Tody E2E Perspective EVLA Advisory Committee Meeting December 14-15, 2004 EVLA Software E2E Perspective.
ICALEPCS’ GenevaACS in ALMA1 Allen Farris National Radio Astronomy Observatory Lead, ALMA Control System.
ICALEPCS 2005 Geneva, Oct. 12 The ALMA Telescope Control SystemA. Farris The ALMA Telescope Control System Allen Farris Ralph Marson Jeff Kern National.
1 Device Controller I/O units typically consist of A mechanical component: the device itself An electronic component: the device controller or adapter.
Metadata for the SKA - Niruj Mohan Ramanujam, NCRA.
SKA Interface Workshop: Dishes External Interfaces Thomas Kusel & Mark Bowen For Dishes consortium Manchester June 2013.
M&CML: A Monitoring & Control Specification Modeling Language
Building a Data Warehouse
Stefan Schleicher Angela Köppl 24 April 2015
Advanced Computer Systems
From LSE-30: Observatory System Spec.
Definition of CIM “CIM is the integration of the total manufacturing enterprise through the use of integrated systems and data communications coupled.
CIIT-Human Computer Interaction-CSC456-Fall-2015-Mr
Computing models, facilities, distributed computing
CANAL NETWORK CONTROL AJAY K BASU
Architecting Web Services
IEEE 802 OmniRAN Study Group: SDN Use Case
Sizing With Function Points
Computing Architecture
How SCADA Systems Work?.
Architecting Web Services
Chapter 19: Architecture, Implementation, and Testing
IEEE Std 1074: Standard for Software Lifecycle
Distribution and components
Active Data Management in Space 20m DG
Understanding the OSI Reference Model
GRID COMPUTING PRESENTED BY : Richa Chaudhary.
Application of ODP for Space Development
Programmable Logic Controllers (PLCs) An Overview.
Chapter 3: Open Systems Interconnection (OSI) Model
Antenna Monitor & Control Subsystem Engineering Requirements
Unit 6: Application Development
Cloud computing mechanisms
OSI Model The Seven Layers
SADT Overall Summary Total ICD count is currently 37 system level ICDs across 6 Elements LFAA 3 ICDs DISHES 7 ICDs CSP 12 ICDs TM ? Unable to proceed.
An Introduction to Software Architecture
A Component-based Architecture for Mobile Information Access
Technical Capabilities
SAMANVITHA RAMAYANAM 18TH FEBRUARY 2010 CPE 691
Chapter 2: Operating-System Structures
Middleware, Services, etc.
Introduction to Operating Systems
Motivation, Terminology, Layered systems (and other random stuff)
Applying Use Cases (Chapters 25,26)
Applying Use Cases (Chapters 25,26)
Software interoperability in the NGN Service layer
SDP-lead Interfaces Summary
Design Yaodong Bi.
Basic organizations and memories in distributed computer systems
IoT Requirements for Networking Protocols Sadoon Azizi Department of Computer Engineering and IT.
OSI Reference Model Unit II
Chapter 2: Operating-System Structures
<Your Team # > Your Team Name Here
Project Management Unit #2
OSI Model 7 Layers 7. Application Layer 6. Presentation Layer
COMPONENT – BASED SOFTWARE ENGINEERING MODULE 2 – SECOND SEMESTER MKHIZE, BSC HONS COMPUTER SCIENCES, DIP IT, ICDL.
Logical Architecture & UML Package Diagrams
Presentation transcript:

SDP Interface Identification Simon Ratcliffe, Paul Alexander, Bojan Nicolic and Chris Broekma

Interfaces Physical / Mechanical Power Data Transport Telescope Manager Central Signal Processor User Supplied Equipment Human-Machine Interface Performance Aspects

Physical / Mechanical Location (on/off site) of SDP may differ between Australia and SA. SDP itself may be physically split along functional lines. Provision of racks could be complicated by heterogeneous design with wide variety of requirements (e.g. extra depth, water cooling, etc...) Perhaps an ITT across CSP, SDP and TM could like at something like Open Compute and see how this could meet the requirements. Deployment model will be essential to mesh with the early science / commissioning program.

Power Obviously an important criteria – presumably the interface driven from the system level and so SDP will be provided with a power budget ? Decisions around power provision, e.g. DC vs AC will probably need to be ITT driven. This decision must be made as early as possible. Power availability and cost curves should be included in the interface to allow energy efficient scheduling. Remote power switching required to the rack level at the very least.

Data Transport Current understanding that intra-SDP communications will be handled by SDP, but all external interfaces (CSP, TM, etc..) provided by SaDT. Common protocol for bulk exchange (CSP internal, CSP → SDP, SDP → external) would be highly beneficial. Energy considerations for bulk data are of prime importance, particularly on the receiving end. Suggest SDP lead (or co-lead) of ITT on this topic.

Telescope Manager Likely to be most complex interface involving SDP. Control and Monitoring will be via single SDP proxy that provides a somewhat “black box” view of the SDP. Should provide a rich enough interface to allow scheduling and resource management. Meta-data interface likely to be separate

Telescope Manager Most critical aspect relates to metadata: Some metadata is time critical e.g. antenna activity sensors. Different observations require different pre-defined sets of sensors. In general, any piece of metadata should be obtainable from TM. Operations concept is important – we may have to provide ILS interfaces directly to the end user, rather than via TM. SDP also needs to provide a variety of meta information back to TM such as calibrator catalogues, pointing model parameters etc...

Central Signal Processor Primary concern is data rate and when we can put specifications to this. Boundary is extremely fluid, and depends on physical implementation (e.g. software correlator) and functional allocation. Most of the ingest functions (spectral/temporal averaging, data corrections, format conversions, gain calibration etc...) could be performed on either side of the boundary. One possibility is to simplify the CSP->SDP interface at the expense of increased data rate i.e. provide more flexibility in the SDP rather than CSP. Timing and synchronisation: Slaved to time information encoded in CSP data and TM metadata.

User Supplied Equipment Not mentioned in baseline design. Should consider catering for this eventuality, particularly from the flexibility it brings. SDP could provided packaged data stream with raw data, meta data and calibration information.

Human-Machine Interface We will have a number of user facing interfaces, including those for expert users of the system. Will we have common User Interface guidelines to control aspects such as look and feel, authentication and authorisation, interface technologies etc... Does SDP provide interfaces to realtime data quality metrics, or simply pass these to TM ?

Performance Aspects Many of the SDP performance requirements will be impacted by upstream components. Need to ensure that the allocation of the system error budget is done in an holistic fashion. Interfaces that specify or constrain such performance parameters need to be closely monitored.

Major Questions to Answer Functional allocation boundaries between various subsystems, particularly SDP ↔ CSP and SDP ↔ TM. Phase 1 constraints: Power Physical Space Integration of precursor technology Location of SDP (baseline design calls for entire SDP to be located in Cape Town & Perth) Role of ITTs and how they will be formed.

Interfaces Summary Function TM SaDT CSP Infrastructure SDP → Users Ingest (bulk) Physical Logical Ingest (meta) M&C Data Transport (site → off-site) (site → world) Power Cooling Thermal Presentation Layer Logical ? Logical?