Skip to content
Space
Express Interest

Flagship Architecture & Leadership Track

Satellite Engineering

From First Principles to Spacecraft Systems Architect

Develop the systems thinking, engineering judgement and architecture capability required to architect complex satellite missions and lead multidisciplinary spacecraft engineering programs.

Design, Analyse, Architect, Build, Test, Operate, Lead

For Systems Leads · Principal Engineers · Engineering Managers · CTOs · Chief Architects · Senior R&D Engineers

Explore the 12-Week Architecture View Program Outcomes
See Career Pathways
  • 12 Weeks
  • 120 Contact Hours
  • Architecture Studio
  • Satellite Digital Twin
  • CubeSat Flatsat
  • SRR · PDR · CDR

Reference spacecraft

6U Earth Observation Satellite

SSO · 500–550 km
Payload
Optical EO
ADCS
3-axis · RW + MTQ
EPS
Deployable solar + Li-ion
TT&C
S-band
Downlink
X-band
OBC
Flight computer + edge
FDIR
Safe mode
End of life
Disposal strategy

Review gates

  1. MCR
  2. SRR
  3. PDR
  4. CDR
  5. TRR
  6. ORR
  7. MRR
Illustrative reference architecture — an educational mission, not a flight design.

Course thesis

Engineering beyond individual subsystems

The program is built around the complete spacecraft lifecycle — from the first statement of mission need to the technical and commercial decisions that commit a program to flight.

  1. 01Mission Need
  2. 02Requirements
  3. 03Architecture
  4. 04Trade Studies
  5. 05Detailed Engineering
  6. 06Simulation
  7. 07Prototype / Flatsat
  8. 08Verification & Validation
  9. 09Mission Operations
  10. 10Technical & Commercial Decision

The objective is not merely to learn how each subsystem works.

The objective is to learn how technical decisions across orbit, payload, power, ADCS, communications, avionics, structures, thermal, propulsion, software, reliability, operations and cost interact at spacecraft level.

  • Orbit
  • Payload
  • Power
  • ADCS
  • Communications
  • Avionics
  • Structures
  • Thermal
  • Propulsion
  • Software
  • Reliability
  • Operations
  • Cost

Mission architecture

A Satellite Mission Is a System-of-Systems

A spacecraft cannot be architected in isolation. Orbit, launch interface, payload, ground network, mission operations and downstream user needs must be designed as one mission system.

Mission objective

System-of-systems architecture

  • Space SegmentBus, subsystems, flight software, onboard autonomy
  • PayloadInstrument, onboard processing, calibration
  • Launch SegmentLauncher, deployer interface, orbit injection
  • Ground SegmentStations, network, TT&C and payload data reception
  • Mission OperationsPlanning, commanding, anomaly response, end of life
  • Data / User SegmentProcessing, data products, delivery to users

Interfaces ICDs · RF links · launch interface · data formats · operations procedures · end-to-end budgets

Mission capability

Who this program is for

Architecture & Leadership Track

This program develops the systems thinking, engineering judgement and architecture capability required to architect complex satellite missions and lead multidisciplinary spacecraft engineering programs.

This Architecture & Leadership Track is designed as an advanced Satellite Systems Engineering Course in India for experienced engineers and technical leaders working toward spacecraft systems and mission architecture responsibilities.

  • Systems Lead

    Translate mission objectives into coordinated spacecraft-level technical decisions across every subsystem team.

  • Principal Engineer

    Extend deep subsystem expertise into cross-disciplinary judgement on margins, interfaces and failure behaviour.

  • Engineering Manager

    Run spacecraft programs through review gates with clear technical baselines, risk ownership and decision authority.

  • CTO

    Connect mission capability, engineering strategy, technology roadmap, cost, supply chain and organisational execution.

  • Chief Architect

    Develop and defend system architecture, interfaces, trade-offs, technology choices and risk posture.

  • Senior R&D Engineer

    Position research and new technology against real spacecraft constraints, readiness levels and qualification paths.

  • Experienced Engineers Transitioning into Space Systems

    Bring automotive, avionics, energy, telecom, embedded or defence experience into the spacecraft domain with a rigorous systems foundation — rather than learning one subsystem at a time.

The program develops capabilities relevant to progression toward senior spacecraft systems and architecture roles. It does not itself confer job titles.

Program at a glance

Twelve weeks of structured engineering effort

Duration
12 Weeks
Core Contact Hours
120 Hours
Recommended Project / Architecture Work
40–80 Hours
Total Learning Effort
160–200 Hours
Delivery
Engineering Lecture + Architecture Studio
Primary Capstone
6U Satellite Reference Mission
Physical Engineering
CubeSat Engineering Model / Flatsat
Digital Engineering
Satellite Digital Twin
Formal Reviews
SRR · PDR · CDR · Mission Readiness

Self-paced prerequisite support

Week 0 · Engineering Readiness

Before Week 1, participants refresh the mathematics, programming, engineering and space fundamentals the program builds on.

Experienced participants may validate readiness through a diagnostic assessment.

Mathematics

  • Linear algebra
  • Vectors and matrices
  • Differential equations
  • Probability
  • Numerical methods

Programming

  • Python
  • NumPy
  • SciPy
  • Jupyter
  • Git

Engineering

  • Electronics
  • Mechanics
  • Thermodynamics
  • Signals
  • Control systems
  • Dimensional analysis

Space Fundamentals

  • Spacecraft terminology
  • Coordinate frames
  • Orbit fundamentals
  • Satellite classes
  • Mission lifecycle

One reference mission

One Mission. Twelve Weeks. Increasing Engineering Fidelity.

Every week modifies the same spacecraft architecture. Decisions made in one subsystem become constraints for the next — exactly as they do on a real program.

Reference mission · Capstone

6U Earth Observation Satellite

Orbit
500–550 km Sun-Synchronous Orbit
Mission
Earth Observation
Payload
Optical EO payload
Design Life Target
3 years
Life Extension Trade
Evaluate extension toward 5 yearsBattery cycling · radiation · orbit decay · propulsion · reliability · degradation · commercial value
Power
Deployable solar arrays + Li-ion battery
ADCS
Three-axis stabilised, reaction wheels + magnetorquers
TT&C
S-band
Payload Downlink
X-band
Computing
Onboard flight computer + edge processing
Safety
FDIR + safe mode
Sustainability
Collision avoidance / end-of-life disposal strategy

Coupled decisions

  • ADCSinteracts withPayload

    ADCS decisions must support payload pointing accuracy, stability and agility.

  • Powerinteracts withPayload + Comms

    Power must support payload imaging and communications passes — including in eclipse.

  • Thermalinteracts withBattery + Avionics

    Thermal design must hold battery and avionics within their operating limits.

  • Datainteracts withStorage + Downlink

    Data generation must match onboard storage and downlink capacity.

  • Launch + Orbitinteracts withMission

    Launch and orbit choices drive lifetime, radiation dose, coverage and economics.

Engineering fidelity

  1. Concept BaselinePhase IWeeks 1–3
  2. Preliminary DesignPhase IIWeeks 4–8
  3. Verification-Ready BaselinePhase IIIWeeks 9–10
  4. Operational BaselinePhase IVWeeks 11–12

Continuous engineering artefacts

Your Spacecraft Architecture Dossier

Artefacts are not submitted once and forgotten. They are opened in the week they become relevant and maintained under configuration control until the final review.

Definition & Architecture

  1. Mission Definition
  2. Concept of Operations
  3. Mission Requirements
  4. System Requirements
  5. Subsystem Requirements
  6. Requirements Traceability Matrix
  7. Functional Architecture
  8. Physical Architecture
  9. Interface Architecture
  10. Interface Control Document

Engineering Budgets

  1. Mass budget
  2. Power budget
  3. Energy budget
  4. Data budget
  5. Link budget
  6. Delta-V budget
  7. Thermal budget
  8. Pointing budgetAccuracy · knowledge · stability · jitter
  9. Performance / Image Quality budgetImage-quality allocation · GSD-related dependencies

Engineering Governance

  1. Risk Register
  2. FMEA / FMECA
  3. Verification Matrix
  4. Technology Readiness
  5. Cost Model
  6. Schedule
  7. Make / Buy Decisions
  8. Configuration Baseline
  9. Engineering Margin Policy
  10. Architecture Decision Records

Governance artefact

Engineering Margin Policy

Architecture is not only about meeting nominal requirements; it is also about preserving quantified margin as the design matures.

  • Mass
  • Power
  • Energy
  • Data
  • Thermal uncertainty
  • Processor load
  • Link margin
  • Propellant reserve
  • Schedule reserve

Review questionWhat margin remains, and what assumptions consume it?

Architecture Decision Records

ADR-ADCS-004

Three-wheel vs four-wheel reaction-wheel architecture

Each major decision is logged with its options, criteria, rationale, assumptions, risks and the trigger that would reopen it. Illustrative example:

Question
Must three-axis payload pointing survive a single reaction-wheel failure?
Options considered
Three orthogonal wheels with magnetorquer backup · four wheels in a pyramid configuration
Evaluation criteria
Pointing after a wheel failure, mass, power, volume, cost, momentum management
Selected option
Four-wheel pyramid
Rationale
Preserves imaging capability after a single wheel failure across the 3-year design life
Assumptions
Supplier wheel reliability data; volume available in the 6U layout
Risks
Power and volume margin consumption; wheel-speed zero crossings
Revisit trigger
Design life extended toward 5 years, or power margin falls below policy

Full 12-week structure

The 12-Week Architecture

Four phases take the reference mission from concept to a defended architecture. Each week pairs engineering lectures with an architecture studio and ends with artefacts that feed the dossier.

4 phases · 12 weeks · select a week to see topics, decisions, studio work and deliverables.

Phase I · Weeks 1–3

Mission & Systems Architecture

Define the mission, the orbit and the pointing problem before a single subsystem is sized.

Review gates: MCR · SRR

Core topics
  • Global and Indian space ecosystem
  • Mission objectives
  • Stakeholders
  • Concept of Operations (ConOps)
  • Requirements engineering
  • NASA / ECSS lifecycle concepts
  • TRL / MRL
  • MBSE
  • SysML / Capella
  • Digital engineering
Architecture decisions
  • What is the mission actually for, and who decides whether it succeeded?
  • Which requirements are true constraints, and which are design choices in disguise?
Labs / studio
  • Stakeholder and ConOps workshop
  • System context modelling in an MBSE tool
Deliverables
  • Mission Definition Document
  • Concept of Operations
  • Top-Level Requirements
  • System Context Diagram

MCR · Mission Concept Review

Phase II · Weeks 4–8

Spacecraft Subsystem Architecture

Architect each subsystem against the shared mission baseline and keep every budget closed.

Review gates: PDR

Phase III · Weeks 9–10

Payload, Verification & Qualification Planning

Put the payload at the centre of the architecture, then prove the design can be built and trusted.

Checkpoint: Engineering-model verification campaign + CDR preparation

Phase IV · Weeks 11–12

Operations, Leadership & Architecture

Operate the mission, own the risk and defend the architecture before a review panel.

Review gates: CDR · TRR · ORR · MRR

Continuous track

Satellite Digital Twin

Model → Simulate → Analyse → Fault Inject → Operate

The twin grows one increment at a time alongside the architecture, so each subsystem model is validated against the same mission baseline before it is coupled to the next.

  1. Week 2Orbit TwinPropagation, eclipse and ground contacts
  2. Week 3ADCS TwinAttitude dynamics, sensors and control
  3. Week 4Energy TwinSolar input, battery state of charge, loads
  4. Week 5Thermal TwinHot and cold cases, heater control
  5. Week 7Communications TwinLink margin and contact windows
  6. Week 8Avionics / Flight-State ModelModes, commands and FDIR states
  7. Week 9Payload ModelImaging demand, data volume, pointing
  8. Week 10Fault InjectionInjected faults and recovery response
  9. Week 11Telemetry-Driven Operational ModelOperations driven by live telemetry
  1. Physical Flatsat
  2. Telemetry
  3. Satellite Digital Twin
  4. Mission Control
Physical flatsat, telemetry, digital twin and mission control exchange data in both directions: hardware behaviour calibrates the twin, and the twin drives operations rehearsal and fault analysis.

The Satellite Digital Twin developed in this program is an engineering model whose fidelity increases as simulation, test and telemetry evidence are added. It should not be interpreted as a validated flight digital twin unless validation criteria have been explicitly demonstrated.

Related on this platform: CubeTwin — a CubeSat energy digital twin explores the orbit-power-battery coupling behind the Week 4 Energy Twin.

CubeSat engineering model / flatsat

From Architecture to a Working Engineering Model

Subsystems are laid out on a bench, wired over real spacecraft interfaces and exercised with emulated power, sensors and payload — so integration problems appear on the table rather than in orbit.

  • Command & Data Handling

    • OBC

  • Power

    • EPS
    • Battery / battery emulator
    • Solar-array emulator

  • Attitude & Navigation

    • Reaction wheel
    • Magnetometer
    • IMU
    • GNSS

  • Communications

    • Radio
    • Antenna

  • Payload

    • Payload emulator

  • Thermal

    • Thermal sensors

Data bus CAN / I2C / SPI interfaces

Educational engineering model. The flatsat is a CubeSat-class educational engineering model for integration, test and operations practice. It is not flight-qualified hardware unless explicitly validated through a separate qualification campaign.

Engineering review gates

Review culture, not only classroom assessment

Participants present, defend and close actions at formal gates modelled on spacecraft program reviews, with entry criteria, a review panel and recorded action items.

  1. Week 1

    MCR Mission Concept Review

    Is the mission need clear and the concept feasible?

  2. Week 3

    SRR System Requirements Review

    Are the requirements complete, verifiable and traceable?

  3. Week 7

    PDR Preliminary Design Review

    Does the preliminary architecture close with margin?

  4. Week 12

    CDR Critical Design Review

    Is the detailed design mature enough to build and verify?

  5. Week 12

    TRR Test Readiness Review

    Are the test article, procedures and facilities ready to verify the CDR baseline?

  6. Week 12

    ORR Operational Readiness Review

    Can the team operate the mission and handle anomalies?

  7. Week 12

    MRR Mission Readiness Review

    Is the complete mission system ready, and can its architecture be defended?

Engineering-model verification occurs throughout the course, while formal review gates represent the progressive maturity of the mission architecture and test baseline. In this compressed format, CDR, TRR, ORR and MRR are held in sequence in the Week 12 studio.

Program outcomes

What You Should Be Able to Do

After successfully completing the program and capstone, participants should be able to:

  1. Translate mission needs into spacecraft-level requirements.
  2. Develop a Concept of Operations.
  3. Perform first-order mission and orbital analysis.
  4. Develop spacecraft system and subsystem architecture.
  5. Maintain mass, power, energy, data, link and Delta-V budgets.
  6. Perform subsystem-level trade studies.
  7. Develop ADCS, EPS, communications, avionics, thermal and structural architecture.
  8. Define payload-to-platform requirements.
  9. Develop interface control documentation.
  10. Create reliability and FMEA/FMECA artefacts.
  11. Plan verification, qualification and acceptance campaigns.
  12. Prepare for and participate in SRR, PDR and CDR.
  13. Operate a CubeSat-class engineering model / mission simulation.
  14. Use a satellite digital twin for engineering and operational analysis.
  15. Evaluate cost, risk, supplier and make/buy decisions.
  16. Defend spacecraft architecture before a technical review panel.

Final deliverables

Graduate with an Engineering Portfolio — Not Just a Certificate

Twenty reviewable artefacts, organised the way a spacecraft program would file them.

Mission

  • 01Mission Definition Document
  • 02Concept of Operations
  • 03Requirements Specification

Architecture

  • 04Spacecraft Architecture
  • 05Interface Control Document

Analysis

  • 06Mass Budget
  • 07Power & Energy Budget
  • 08Link Budget
  • 09Data Budget
  • 10Delta-V Budget
  • 11Thermal Analysis
  • 12ADCS Model

Verification

  • 13Reliability / FMEA Package
  • 14Verification & Validation Matrix
  • 15Test Plan
  • 16Flatsat Demonstrator

Operations

  • 17Satellite Digital Twin
  • 18Mission Operations Concept

Leadership

  • 19Cost & Risk Model
  • 20Spacecraft Architecture Dossier

Roles & progression

Career & Leadership Pathways

The program develops capabilities applicable to spacecraft systems engineering, mission architecture and multidisciplinary engineering leadership. Eligibility for specific roles depends on prior education, domain experience and demonstrated engineering competence.

Category 1

Spacecraft & Satellite Systems

  • Spacecraft Systems Engineer
  • Satellite Systems Engineer
  • Space Mission Systems Engineer
  • Spacecraft Systems Architect
  • Satellite Systems Architect
  • Mission Architect
  • Space Systems Technical Lead
  • Spacecraft Technical Program Lead
  • Spacecraft Chief Engineer

Category 2

Advanced / Leadership Pathways

For experienced engineers, relevant progression pathways can include the roles below. Course completion alone does not confer senior titles such as CTO, Chief Architect or Director.

  • Principal Space Systems Engineer
  • Lead Systems Engineer
  • Systems Engineering Manager
  • Spacecraft Architecture Lead
  • Chief Systems Engineer
  • Chief Architect
  • Director — Space Systems Engineering
  • Director — Satellite Engineering
  • CTO — Space / Satellite Technology

Category 3

Specialist Technical Roles

  • ADCS / GNC Engineer
  • Orbital Mechanics Engineer
  • Mission Analysis Engineer
  • Spacecraft Power Systems Engineer
  • Battery Systems Engineer
  • Thermal Engineer
  • Spacecraft Structural Engineer
  • Propulsion Systems Engineer
  • RF / Satellite Communications Engineer
  • Ground Segment Engineer
  • Avionics Engineer
  • Flight Software Engineer
  • Embedded Systems Engineer
  • Payload Systems Engineer
  • AIT Engineer
  • Environmental Test Engineer
  • Reliability Engineer
  • Spacecraft Quality Engineer
  • Space Cybersecurity Engineer
  • Satellite Digital Twin Engineer
  • Mission Operations Engineer
  • Satellite Operations Engineer

Category 4

Research & R&D

  • Satellite Systems Researcher
  • Spacecraft Digital Twin Researcher
  • ADCS Research Engineer
  • Space Power & Battery Researcher
  • Autonomous Space Systems Researcher
  • Space Cybersecurity Researcher
  • Space Communications Researcher
  • Onboard AI Research Engineer
  • ISAM / Space Robotics Researcher

Category 5

Technology & Business

  • Space Technology Consultant
  • Space Systems Consultant
  • Technical Product Manager — Space
  • Satellite Product Architect
  • Space Program Manager
  • Technology Strategy Lead
  • Space Startup CTO
  • Deep-Tech Founder
  • Space Business Architecture Lead
  • Technical Due-Diligence Consultant

Pathways are illustrative. The program does not guarantee placement, and course completion alone does not confer senior titles such as CTO, Chief Architect or Director.

Credential

Certification

The credential recognises completion of the program assessments and a successfully defended capstone. It is awarded by EV.ENGINEER™, the program provider; it is not an accredited academic qualification and does not claim university equivalence.

Primary credential

Advanced Certificate in Satellite Engineering

Architecture & Leadership Track

Satellite Engineering: From First Principles to Spacecraft Systems Architect

Capstone recognition

Spacecraft Systems Architecture Capstone · Successfully Completed

Why this program is different

Seven engineering pillars

Quality is demonstrated through structure: one spacecraft, real review gates and failure as a design input.

  1. One spacecraft for the entire course

    No disconnected modules. Every week modifies the same reference mission.

  2. First principles + architecture

    Calculate and understand before making system decisions.

  3. Physical + digital

    A CubeSat-class flatsat and a satellite digital twin, developed side by side.

  4. Formal engineering reviews

    SRR → PDR → CDR → Mission Readiness, run as review gates rather than exams.

  5. Failure engineering

    Detect, isolate, recover and learn from injected faults.

  6. Mission operations

    Operate the mission architecture, not only design it.

  7. Engineering leadership

    Connect technical choices to cost, schedule, supply chain and risk.

Engineering learning model

Calculate before you decide. Fail before you fly.

Every topic moves through the same loop, from first-principles calculation to a decision defended in review.

  1. 1Calculate
  2. 2Simulate
  3. 3Build
  4. 4Test
  5. 5Fail
  6. 6Diagnose
  7. 7Improve
  8. 8Defend

Worked example

Battery

  1. Calculate eclipse requirement
  2. Simulate cycling
  3. Validate power architecture
  4. Inject degraded capacity
  5. Estimate SOC / SOH
  6. Diagnose impact
  7. Revise engineering margin

Tools & engineering stack

Engineering Tools & Open Technical Stack

Tools used for mission analysis, simulation, modelling, flight-software learning, RF experimentation and systems engineering.

Mission / Orbit
  • GMAT
  • Orekit
  • Python / Skyfield
ADCS
  • Basilisk
  • NASA 42
Flight Software
  • NASA cFS
  • JPL F Prime
  • FreeRTOS / Zephyr
MBSE
  • Capella
  • SysML concepts
CAD / Analysis
  • FreeCAD / SolidWorks / NX concepts
  • Ansys / Nastran concepts
  • KiCad
RF
  • GNU Radio
  • SatNOGS
Data / AI
  • Python
  • PyTorch
  • Earth observation datasets

Tool selection may vary by cohort, licensing and laboratory availability. Naming a tool does not imply a partnership with, or endorsement by, its developer — including NASA, JPL or commercial software vendors.

Industry and reference frameworks

Frameworks are referenced for educational context only and do not imply endorsement by, or affiliation with, NASA, ESA/ECSS, CCSDS, Cal Poly or IN-SPACe.

Architect the Mission. Defend the Decisions.

Move beyond subsystem familiarity and develop the systems-level engineering judgement required to connect mission objectives, spacecraft architecture, verification, operations, risk and technology strategy.

Express Interest Explore Space R&D

Cohort dates, format, fees and selection criteria will be published for each cohort.

Satellite Engineering is an EV.ENGINEER™ professional program within the EV Society™ Space initiative. Commercial arrangements, where applicable, are handled by iTelematics Software Private Limited.

Program information last reviewed: .