WBS 3.2.4 & 3.2.5 AO Controls
Jason Chin, Don Gavel, Erik Johansson, Mark Reinig
Design Meeting (Team meeting #10)
Sept 17th, 2007
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.
2
WBS Definitions
•
3.2.4.1 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.
•
3.2.4.2 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.
3
WBS Definitions (contd)
•
3.2.5 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.
•
3.2.5.1 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.
4
WBS Definitions (contd)
•
3.2.5.2 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.
•
3.2.5.3 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.
5
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
6
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
7
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.
8
WBS 3.2.4.1 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.
9
WBS 3.2.4.2 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.
10
WBS 3.2.5 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 3.2.5.1, 3.2.5.2, and 3.2.5.3.
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
11
Block Diagram of Interfaces
External nonRT Interfaces
(Observ,
Calib, etc.)
AO
Sequencer
(Supervisory
Controller)
Opto-mech
Devices
Sensors
Motion
Control
Real Time
Computer
Correctors
WBS 3.2.4 and 3.2.5 Controls
External
RT Interfaces
(telescope,
laser, telem,
etc)
12
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)?
13