1. CINEMA System Engineering
Dave Curtis
CINEMA

2. System Engineering Tasks
Requirements Flowdown
Identify top-level science and programmatic requirements
Flow those requirements down to subsystems
Involves some system-level design
Verify by analysis and/or test that each requirement is met
Interface Control, Specifications
Document and track interfaces between subsystems
System Design
Top-level design of how the subsystems work together
Resource Allocation and Tracking
Mass, Power, Link Margin, Pointing, etc.
Money, schedule, manpower resources typically tracked by Project Manager
Technical Coordination and Evaluation
Coordinate the various technical disciplines and subsystem leads to ensure that requirements are being met
Perform technical reviews with independent reviewers to identify any issues
Reliability Engineering and Risk Management
Identify potential technical risks and failure modes and mitigate where possible
System Integration and Test Coordination
Ensure adequate testing to verify all requirements
CINEMA

3. Requirements
Top level science and programmatic requirements identified in the CINEMA NSF AO and Proposal
Requirements have been extracted into a document and flowed down to the subsystem
ftp://apollo.ssl.berkeley.edu/pub/cinema/2.%20Systems/CINEMA_Requirements.xls
Flowdown depends on system design, which has evolved a bit since the proposal based on design trade studies
Subsystem allocations still in work
Some requirements cannot be nailed down until we have a launch selected
Orbit, Launch loads, etc.; nominal values assumed for now
Requirements organized as follows:
Level 1 Science, Programmatic, and Mission Assurance
Level 2 Subsystems (STEIN, MAGIC, ACS, Telecom, etc)
Level 3 Components (MAGIC Boom, Torque Coils, etc)
Documented requirements provides an agreed upon baseline for the system and subsystem engineers to design and test to, along with a rationale to remind us what we are losing if we cannot meet the requirements
The System Engineer controls the requirements document.
CINEMA

4. Sample Requirements
CINEMA

5. Verification Each requirement must be verified during system testing
Verify early at subsystem/component level where possible
Verify again at the full system level
Verify environmental requirements
Survive launch loads
Operate in vacuum and over temperature
Some requirement verified by analysis, but test is preferred
Ready to launch when all requirement verified
System Engineer tracks verification of requirements
CINEMA

6. Interface Control Documents
An Interface Control Document (ICD) describes how one subsystem or component interacts with another or with the system as a whole
It augments the requirements document with detailed information about how the interaction between subsystems takes place such that an engineer can design his subsystem.
It includes things like mass and power, interface voltages, currents, signals, timing diagrams, pinouts, etc.
The System Engineer, together with the subsystem engineer, develops the ICD for the subsystem
MAGIC ICD first draft provided by IC. Others to follow as needed
CINEMA

7. Specifications
Specifications describe the implementation of a component or subsystem
Includes details of how the item works, User information, handling details, etc.
May take the place of an ICD in some cases
Commercial equipment typically includes a specification or users manual
Specifications provide a way of documenting the design as it progresses
Important due to the transient nature of the students who are doing much of the CINEMA development
Specifications are not formally controlled documents; they are expected to evolve with the design and include by reference the schematics, listings, and other low level design information
All controlled documentation available on the CINEMA Web page
ftp://apollo.ssl.berkeley.edu/pub/cinema
All working documentation on the CINEMA Wiki page
Password controlled.
CINEMA

8. System Design Current top-level design shown in following slides
Design continues to evolve
Design to meet requirements
Science, Technical, and Programmatic
Details of subsystem designs in later talks
CINEMA

9. Electrical Block Diagram
CINEMA

10. Mechanical Configuration
CINEMA

11. Ground System
CINEMA

12. Operations Launched powered-off Power up into Safe mode Contact Ground
power-up on deployment from P-Pod
Power up into Safe mode
Instrument and ACS Off
Transceiver powered on, listening
Contact Ground
Set-up time-tagged contact windows so transceiver can be powered off between passes, freeing up power for ACS
MAG Boom Deploy
Determines major axis for stable spin
Deploys magnetometer for ACS
MAG Cal
Use torque rods to determine MAG orientation
ACS Acquisition Mode
Detumble, Spin up, Sun-normal spinning
Precession Mode
Reorient to Ecliptic Normal Spin (requires ground interaction)
Science Mode
Power off ACS, Power up instruments
Return to ACS Mode
Periodic drift correction
Return to Safe Mode
In the event of problems (low power, no ground contact, system reset)
Power up transceiver, wait to be contacted.
CINEMA

13. Resource Budgets
The following budgets are based on the proposal configuration
Design trades continue to refine the configuration
CINEMA

14. Mass
CINEMA

15. Power Generation
CINEMA

16. Battery
CINEMA

17. Power Usage
Telecom Power
CINEMA

18. Telecom
Assumes 1 pass/day for command / housekeeping via MHX2400 transceiver
Remaining passes for Science recorder download with S-band transmitter
CINEMA

19. Reliability
Good design practices, workmanship standards, and high quality parts are key to reliable systems
But are limited by the reality of limited cost and schedule
On such a severely cost constrained mission as CINEMA, reliability is obtained by primarily through testing
Identifies design flaws, poor quality parts, bad workmanship
Test early, test often
Include margin testing (voltage, temperature, frequency, etc)
Include ‘test-as-you-fly’
CINEMA