Configuration Management for Model-Based Design of Software

Team: Issmale Bekri, Asray Gopa, Arjun Patel, Akhil Pallem

Client: Scott Meyers, Collins Aerospace

Course: COM S 402 - Senior Design Project

Instructor: Simanta Mitra

TA: Scott Song

Fall 2025

Chapter 1 - Requirements

1.1 Purpose

Engineers using Cameo, Simulink, Git, and Python-based testing tools currently lack reliable cross-tool traceability across the system development lifecycle. While each tool provides strong domain-specific capabilities, the absence of an integrated traceability mechanism makes it difficult to understand how requirements propagate through models, code, and verification artifacts. This gap is typically addressed through manual processes such as spreadsheets or static trace matrices, which do not scale well and are prone to human error.

Certification processes in the aerospace domain require clearly defined baselines, documented version lineage, and robust impact analysis capabilities to demonstrate compliance. When traceability is incomplete or inconsistent, engineering teams face increased certification risk, longer review cycles, and reduced confidence in change decisions.

This project provides a unified system for tracking and analyzing lifecycle artifacts across traditionally siloed engineering platforms. By integrating requirements, models, and code into a single traceability framework, the system enables comprehensive impact analysis, improves development visibility, and supports streamlined certification readiness. The system is designed to serve as a trusted source of traceability evidence, reducing manual effort while increasing confidence in system-level changes.

1.2 Scope

The system includes the following functional areas:

Requirements Ingestion

Import and normalize SysML requirements from Cameo, including hierarchical parent–child relationships, requirement attributes, and existing traceability links. Imported requirements are represented as structured artifacts that can be queried and linked across the lifecycle.

Model Ingestion

Import Simulink model elements, including blocks, signals, and associated requirements. The system supports automated mapping between Simulink elements and generated C code functions, enabling traceability from requirements through executable implementations.

Code and Test Linkage

Automatically identify and link C source code functions to Python-based test procedures. This establishes bidirectional traceability between implementation and verification artifacts, enabling users to determine both which tests validate a given function and which functions satisfy a given requirement.

Graph-Based Storage

Store all artifacts and relationships within a Neo4j graph database using a normalized graph schema. The graph structure enables efficient traversal across artifacts, supports complex traceability queries, and allows relationships to evolve as the system changes.

Impact Analysis

Perform graph-based impact analysis to identify downstream effects of changes across requirements, models, code, and tests. This allows users to assess the scope of changes before implementation and supports informed decision-making during system evolution.

Baseline and Version Tracking

Create, store, and retrieve baseline snapshots containing all artifacts and relationships at a specific point in time. Baselines include version lineage information to support audits, certification activities, historical analysis, and regression investigation.

1.3 Definitions and Acronyms

1.4 Users

The system is intended for the following user groups:

Aerospace Engineers

Primary users who develop and maintain requirements, models, and code. These users require intuitive visibility into cross-tool dependencies and the ability to assess the downstream impact of changes before modifying system artifacts. Common questions include determining which requirements are affected by a model change or which code functions implement a specific requirement.

Software Integrators

Users are responsible for coordinating and integrating components across the development lifecycle. These users require end-to-end visibility into how requirements flow through models, and code in order to evaluate system-level integration risks and understand the implications of interface or implementation changes.

Certification Authorities

Reviewers are responsible for validating compliance with certification standards. These users require access to complete traceability data, baseline snapshots, and version history to verify that all requirements are fully implemented, verified, and appropriately documented.

1.5 Constraints

The system must adhere to the following constraints:

1.6 Assumptions

The system design is based on the following assumptions:

Chapter 2 - Design

2.1 System Overview

Our system integrates four major engineering tools—Cameo (SysML), Simulink, and GitLab—into a unified configuration-management platform. Each tool outputs artifacts that flow through custom loaders into a Neo4j graph, where traceability, version history, and impact analysis are performed. The frontend visualizes these artifacts as an interactive graph.

System Components:

2.2 Architecture Breakdown

2.2.1 Cameo Integration

Purpose: Convert SysML requirements from Cameo into graph artifacts that can be linked to downstream models and code.

Implementation Steps:

  1. Used Collins Aerospace Cameo access to download existing requirement models.
  2. Exported the Cameo model to a consistent JSON format.
  3. Processed the exported JSON using a custom parser that extracts:
    • requirement ID
    • name & description
    • parent–child structure
  4. Created graph nodes for each requirement in Neo4j.
  5. Preserved hierarchical relationships.
  6. Ensured requirements have IDs for matching with Simulink, code, and tests.

2.2.2 Simulink Integration

Represent Simulink model elements as graph artifacts and link them to upstream requirements.

Implementation Steps:

  1. Used MATLAB Simulink Artifacts to open .slx files from the provided Simulink models.
  2. Extracted blocks, block types, paths, subsystem hierarchy, and signal connections.
  3. For each block, create a corresponding graph node with metadata (sid, name, block type).
  4. Captured internal connections between blocks (in/out ports → edges).
  5. Preserved hierarchy so that nested subsystems appear in the graph as parent–child structures.
  6. Enabled these blocks to be linked later to code files and test artifacts.

2.2.3 Git + Version History Integration

A. GitLab Integration (Code Traceability)

B. Graph-Based Version Control (Snapshot System)

2.2.4 Neo4j Schema

Node Types:

Relationship Types:

These relationships power all analysis and visualization.

2.2.5 Impact Analysis Engine

Impact analysis answers: "If this requirement changes, what downstream artifacts are affected?"

Implementation:

2.2.6 Baseline + Versioning

Purpose: Capture the state of the system at any point in time.

Functionality:

2.3 API Documentation

GET /api/requirements

Purpose: Retrieve all requirements stored in the system, with optional filtering.

Input:

Output:

[
  {
    "id": "REQ-001",
    "name": "System shall ...",
    "description": "...",
    "type": "HighLevel"
  }
]

GET /api/requirements/{req_id}

Purpose: Retrieve a single requirement and its full child hierarchy.

Example Request: GET /api/requirements/REQ-001

Output:

{
  "id": "REQ-001",
  "name": "...",
  "children": [
    {
      "id": "REQ-001.1",
      "children": []
    }
  ]
}

GET /api/requirements/hierarchy

Purpose: Return the complete requirement tree (all root requirements and their descendants).

Output:

[
  {
    "id": "REQ-1",
    "name": "Top-level Requirement",
    "children": [...]
  }
]

GET /api/requirements/stats

Purpose: Return basic statistics about the requirement dataset.

Output:

{
  "total": 120,
  "types": 4,
  "with_children": 89,
  "with_traces": 42
}

GET /api/code-file?file_path=...

Purpose: Retrieve C code extracted from Simulink auto-generated code.

Input (Query Parameters):

Output:

{
  "model_name": "ControllerModel",
  "file_path": "R2025b/.../Controller.c",
  "content": "int step() { ... }",
  "line_count": 350
}

POST /api/code-references/update

Purpose: Update or attach code-reference metadata to a Simulink block.

Used when connecting blocks to specific lines of code.

Input:

{
  "block_sid": "34",
  "block_path": "<Root>/Gain",
  "file_path": "Controller.c",
  "ref_index": 0,
  "line": 124,
  "code": "y = x * 5;"
}

Output:

{
  "success": true
}

GET /api/artifacts/<artifact_id>/versions

Purpose: Return all version snapshots associated with a specific artifact.

Example Request: GET /api/artifacts/block_123/versions

Output:

{
  "artifact_id": "block_123",
  "versions": [
    {
      "version_id": "v1",
      "timestamp": "2025-01-10T15:30:00Z"
    },
    {
      "version_id": "v2",
      "timestamp": "2025-01-17T09:12:44Z"
    }
  ]
}

GET /api/blocks/with-versions

Purpose: Return all Simulink blocks along with their latest version metadata.

Output:

{
  "blocks": [
    {
      "id": "block_12",
      "name": "Gain",
      "latest_version": "v4"
    }
  ]
}

GET /api/requirements/with-versions

Purpose: Return all requirements with their latest version information.

Output:

{
  "requirements": [
    {
      "id": "REQ-1",
      "name": "System shall...",
      "latest_version": "v3"
    }
  ]
}

GET /api/versions/lineage/<artifact_id>

Purpose: Retrieve the full version lineage (ancestor chain) of a given artifact.

Example Request: GET /api/versions/lineage/REQ-12

Output:

{
  "artifact_id": "REQ-12",
  "lineage": [
    { "version_id": "v1", "parent": null },
    { "version_id": "v2", "parent": "v1" },
    { "version_id": "v3", "parent": "v2" }
  ]
}

POST /api/artifacts/<artifact_id>/snapshot

Purpose: Create a new version snapshot for a specific artifact.

Example Request: POST /api/artifacts/block_45/snapshot

Output:

{
  "status": "snapshot_created",
  "artifact_id": "block_45",
  "version_id": "v7",
  "timestamp": "2025-02-01T10:22:19Z"
}

POST /api/versions/load

Purpose: Load all version metadata from storage into the graph.

Input:

{
  "source": "version_storage"
}

Output:

{
  "status": "versions_loaded",
  "count": 128
}

GET /api/versions/stats

Purpose: Return system-wide statistics about versions.

Output:

{
  "total_versions": 128,
  "versions_by_type": {
    "Block": 82,
    "Requirement": 41,
    "File": 5
  }
}

2.4 UI Design

Main Components:

Visualization Features

Chapter 3 - Work Done (Per Team Member)

Issmale Bekri

Work Completed:

Akhil Pallem

Work Completed:

Asray Gopa

Work Completed:

Arjun Patel

Work Completed:

Technologies we each learned:

Chapter 4 - Results Achieved

4.1 Major Deliverables

4.2 Client Value Delivered

4.3 Limitations

Appendix - Demo Slides

Demo slides available in project repository.

Repository Link

https://git.las.iastate.edu/SeniorDesignComS/2025fall/402c/sd02_configuration_management

Setup Instructions

A. Backend

cd backend
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
python main.py

Neo4j AuraDB credentials are already configured inside config.py. No additional database setup is required unless credentials change.

B. Frontend

cd frontend
npm install
npm run dev

The application will be available at http://localhost:3000.

Contact

Client: Scott Meyers, Collins Aerospace
Email: scott.meyers@collins.com

Team: Iowa State University – COM S 402 – Senior Design