WBS & AO Controls Jason Chin, Don Gavel, Erik Johansson, Mark Reinig Design Meeting (Team meeting #10) Sept 17 th, 2007

2 Agenda WBS Definitions Approach to AO Controls WBS tasks Phasing Deliverables and products from subsystems AO Controls internal and external interfaces. Solicit inputs from members.

3 WBS Definitions Non-Real-Time Control Software –Based on system and operations requirements develop a software architecture and maintenance plan for all remote and automatic real time control software. Also, develop data collection and management systems Non-Real-Time Control Electronics –Based on system requirements and in collaboration with the optical and mechanical designers, develop the electrical system requirements for supporting the optical bench including motors, shutters, filter wheels, and other robotic or remotely operable control stages and devices. Also, determine requirements for drive electronics and control boxes for these stages and the associated cabling, connectors, and interfacing. Also, determine the power requirements and design the control signal and power routing to meet overall system noise requirements (this is exclusive of real-time control and wavefront sensing, which is covered in a separate description). Collaborate with the software team to determine computer interface and operability requirements. Output is an electronic/electrical component and wiring layout, control box placement (in corroboration with the mechanical designer), power load analyses, specifications for components, and review/summary of vendor sources for the components.

4 WBS Definitions (contd) Real-time Control Based on system requirements, operations requirements, and error budgets, develop an architecture for the real-time controller, including both hardware and software configuration. Input to this process includes candidate wavefront sensing, tomography, tip/tilt, and DM control and signal processing algorithms as provided by the system engineering group as a result of trade studies. Design work includes specification of hardware interface requirements, hardware processor speed, data rate, and storage requirements, design of the data flow, design of the algorithm implementation software, and design of the diagnostic and telemetry streams. Work includes analysis and modeling of performance at the low-level of implementation, e.g. taking into account data transmission delays, processor delays, and data resolution RTC Architecture Analysis and Design Study Based on system requirements, operations requirements, and error budgets, develop an architecture for the real-time controller, including both hardware and software configuration. Input to this process includes candidate wavefront sensing, tomography, tip/tilt, and DM control and signal processing algorithms as provided by the system engineering group as a result of trade studies. Output of this process is an analysis of candidate architectures, simulations of expected real-time performance, and guidance (in the form of strawman designs) for the RTC software module definition and RTC hardware module definition tasks.

5 WBS Definitions (contd) RTC Software Module Definition Given the architectural design and results of the RTC design study, specify the software development environment tools required (& analyze vendors of such), develop a software top level block diagram, define software data structures and data flow paths, define software command language for interface to the system controller/user interface, design diagnostic and telemetry streams, specify software module functions at a detailed level. Develop a real-time software implementation and test plan RTC Hardware Module Definition Given the architectural design and results of the RTC design study, perform a rough initial specification of the hardware platform (or platform options, through PDR phase), the hardware interfaces and the required cabling. In consideration of real-time data flow and diagnostic/telemetry streams, determine the overall size, mounting, and power requirements. If specifying custom processor boards (likely, with a transputer/FPGA architecture) design the board layout in conformance with fab-house design rules, specify the component processors and all other components needed to enable assembly of the boards. Develop a hardware acceptance test plan. Specify test equipment needed.

6 Approach Non Real-Time Controls –Create a block-level diagram partitioning the system into its major components –Electronics: Determine motion control system scope based on the major components and inputs from opto-mechanical team. Determine requirements for supervisory controller, diagnostics and calibration controller. Estimate power requirements for each of the components. Generate a draft ICD –Software Use block-level diagram of system to generate a top-level SW architecture. Design the component SW modules Generate a draft ICD –Update functional requirements during the process

7 Approach Real-Time Controls –Determine the basic processing requirements based on the functional requirements, system architecture, and error budgets. –Develop a signal flow concept that can be implemented at the required real-time rates. –Work with calibration, alignment, acquisition, and observing teams to determine telemetry requirements. –Iterate and possibly push back on the requirements at the FRD, SRD, and Science requirements levels. –Update functional requirements during the process

8 Phasing Need inputs from opto-mechanical team regarding the types of devices and numbers of degrees of freedom of motion required for each device. Non-RTC work and RTC work should be able to proceed independently.

9 WBS Deliverables A SW architecture design covering the top-level non-RT controls components: –AO sequencer (AO command processor) –Motion control –Calibration and diagnostics A top-level block diagram showing the architecture of the non-RTC SW A top-level data-flow diagram for the non-RTC SW, showing data paths, descriptions, sizes, and expected data rates. A draft of an interface control document describing all the interfaces of the non-RTC SW. A top-level description of all the non-RTC component SW modules. A revision of the functional requirements pertaining to the non-RTC SW. A high-level description of the command, control, and status interfaces and functions of the AO sequencer. A report summarizing all the above items. A revised WBS dictionary definition. Inputs to appropriate sections of FRD version 2.

10 WBS Deliverables A layout of the component subsystems and their locations Block-level diagrams for the following subsystems: –AO Sequencer (AO command processor or supervisory controller) –Motion controller system –Calibration and diagnostics –Environmental subsystem A draft interface control document (data/control flow, synchronization requirements, etc.) A report summarizing all the above items. A revised WBS dictionary definition. Inputs to appropriate sections of FRD version 2.

11 WBS Deliverables A top-level block diagram showing the architecture of the RTC A top-level data-flow diagram for the RTC, showing data paths, descriptions, sizes, and expected data rates. A draft of an interface control document describing all the interfaces of the RTC, both internal and external. A top-level description of all the RTC component SW modules. A diagram showing the partitioning of the RTC SW modules across the processing elements defined in WBS , , and A revision of the functional requirements pertaining to the RTC. A high-level description of the command, control, and status interfaces and functions of the RTC. Preliminary cost analysis. A report summarizing all the above items. A revised WBS dictionary definition Inputs to appropriate sections of FRD version 2 Inputs to the System Design Manual

12 Block Diagram of Interfaces

13 Issues WBS dictionary needs updating –SW and Electronics support for RTC sensors and correctors is missing. These devices will need power, motion control support, supervisory control SW, etc. –The RTC WBS entry discusses board design and layout, but this is only the system design phase, which is conceptual, so board design is inappropriate. –Do we need vibration compensation (accelerometers and feed-forward compensation)?