AVGS Activity Models
Role-Based Perspectives
Integration Engineer

Integration Engineer Perspective

Consumes decomposed requirements downstream: confirms they are implementable, interface-complete, and verifiable in the Ground Systems environment.

  • Confirm interfaces and data flows are defined
  • Validate testability and verification approach
  • Surface implementation risks early

Primary responsibilities

  • Review lower-level requirements for implementability across Ground Systems components.
  • Confirm that interfaces referenced in requirements are defined, owned, and stable.
  • Validate that requirements can be exercised in integration and verification environments.
  • Flag implementation risks, missing interfaces, or hidden dependencies back to the Systems Engineer.

Day-to-day work activities

  1. Walk each new requirement against the integration architecture and interface catalog.1
  2. Confirm data sources (CJP-accessed data, instrumentation outputs, PSE telemetry) are real and available.2
  3. Propose verification methods: test, demonstration, analysis, inspection.3
  4. Identify lab/rig dependencies and call them out early in the schedule.4
  5. Participate in JAMA readiness gate and ARB when integration impact is non-trivial.5

Verification mapping

Requirement styleDefault verification methodEvidence
Interface / data accessTestLab/rig log + interface trace
Equipment provision (PSE, cradle)Inspection / demonstrationConfigured-item record
Support capability (O-Level)DemonstrationProcedure run record
Health monitoring data supportAnalysis + testData flow trace

Government approvals touched

  • Test Readiness Reviews for integration and verification campaigns.
  • Customer-witnessed demonstrations and acceptance events.
  • Verification close-out evidence packaged into program reviews.

Integration review checklist

  • All referenced interfaces are defined and owned.
  • Required data is available at the integration boundary.
  • Requirement is verifiable with current or planned test capability.
  • No implicit assumptions about Air Vehicle behavior.
  • Edge cases (degraded modes, missing data) are addressed in rationale.