Sectoral Scalability: Structured directly utilizing rigorous Aerospace compliance benchmarks, this architecture possesses the inherent flexibility to be directly scaled horizontally into automotive, heavy industry, and generalized industrial machinery production bands without necessitating fundamental architectural alterations.

Project Portfolio

Current Situation and Problem

Context: The integration environments of autonomous platform products (TB2, AKINCI, etc.) within the defense sector mandate exceptionally unyielding traceability compliance regulations. Every individual physical hardware unit populating the factory grid constitutes an obligatory audit record—demanding absolute clarity regarding which approved procurement batch it originated from, which specific operator configured it at which station, and ultimately, which primary airframe it was deployed into. 

Critical Issues: Extruded in the absence of a synchronized, digitally role-bound administrative control mechanism, the statistical probability of component mismatching or structural clashes across disparate platforms escalates exponentially. Relying solely on manual worksheets and disconnected ERP peripheral data matrices (often completely deviating from true FIFO constraints) actively liquidates any capability to execute conclusive backward root-cause analyses during critical audits.

Solution Architecture and Execution

Architectural Approach: A full 3-tier API architecture was mapped out, relying absolutely on role-based security boundaries and deterministic inventory allocations to effectively neutralize asymmetric data management risks.

Applied Methodology

Hardware (UUID) Serialization Process

Every fully manufactured physical component is actively ingested into the database environment formatted exclusively as a UUID. This explicit parameter securely logs production execution times, specific batch typologies, and precise assembly line trajectory assignments ensuring minimal procedural margin of error:

class Part(models.Model):
    id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
    part_type = models.ForeignKey(PartType, on_delete=models.PROTECT)
    produced_by = models.ForeignKey(Employee, on_delete=models.PROTECT)
    production_date = models.DateTimeField(auto_now_add=True)
    aircraft = models.ForeignKey(Aircraft, null=True, blank=True, on_delete=models.SET_NULL)

Role-Based Access Control (RBAC) Node

Three heavily separated access roles were actively hardened within the “Production” sector to physically enforce robust duty segregation paradigms:

Automated Compatibility Isolation

Configuring a fail-safe framework, the network actively blocks aircraft assembly progressions if human data-input matrices or rogue API requests command conflicting hardware platforms:

def validate_assembly(aircraft_type, part):
    """Halts localized structural crossovers between non-compatible platforms"""
    if part.part_type.platform != aircraft_type.platform:
        raise ValidationError(
            f"{part.part_type.name} part cannot be integrated into {aircraft_type.name} hardware."
        )

Deterministic FIFO (First-In-First-Out)

Systematically overriding serial production degradation factors, the absolute oldest raw hardware components injected sequentially into the shop floor are prioritized aggressively for assembly querying logic:

def allocate_part(part_type, aircraft):
    """Allocate the oldest historical component directly to open assembly cycles"""
    available_part = Part.objects.filter(
        part_type=part_type,
        aircraft__isnull=True,
        is_deleted=False
    ).order_by('production_date').first()
    
    if available_part:
        available_part.aircraft = aircraft
        available_part.save()
        return available_part
    raise StockError("Scheduled integration requirement is functionally out of stock")

Soft-Delete Protocols for Audit Logging

Regardless of whether operational components trigger critical revision recalls or are definitively designated as physical scrap assets, items are structurally preserved and exclusively marked (is_deleted) securing uncompromising standard audit compliance logs.

Results and Operational Gains

Quantifiable Output: (Parameters heavily predicated on deterministic simulation readings scaled via PoC testing conditions)

API Integration Architecture (ERP Readiness)

Operating OpenAPI 3.0 frameworks, explicit documentation bridging was formally generated completely optimized for uninterrupted direct socket channels branching outward toward mainstream industrial managerial hubs (e.g., SAP / Oracle grids).

GET    /api/parts/                 # Index all available active hardware within factory bounds
POST   /api/parts/                 # Declare standard new ingress component parameters
DELETE /api/parts/{id}/            # Classify component strictly as physical scrap (soft-delete record)

GET    /api/aircraft/              # Call active status updates reflecting complete main assembly lines
POST   /api/aircraft/              # Initialize new assembly framework matrix directly onto the line
GET    /api/inventory/stock-levels # Provide real-time operational hardware stock queries (Live Count)

Related Links

 Source Code: Github/aerospace-manufacturing-execution-system

Last Updated: January 2026 | Version 1.0

Scope: An integration application operating on the zero-copy principle, developed to establish data exchange between SCADE’s closed-loop structure and the control layer.

Project Portfolio

Current Situation and Problem

Context: The necessity to migrate the interlocking simulation system (4 tracks, 6 signals, 1 switch) at the ITU Railway Systems Laboratory to a SCADE Display-supported HMI architecture compliant with industrial and certifiable standards. Critical Issues: The absence of a native Modbus interface within SCADE Display and the platform’s closed-network design. The inability of the HMI interface to communicate directly with actual field controllers (HIMA HiMatrix F35), and the lack of dynamic field configuration for IP/port maps.

Solution Architecture and Execution

Architectural Approach

Architectural Constraint Assessment: To preserve DO-178C / EN 50128 certification integrity, the SCADE platform features a “closed system” design philosophy stripped of all asynchronous external network operations. Consequently, for physical PLC integration in the laboratory, developing an independent, externally operating asynchronous middleware layer became mandatory.

A C99 middleware wrapper layer was designed between SCADE’s generated code and the libmodbus library:

Communication Flow

Applied Methodology

• Zero-Copy Integration: Copy overhead was eliminated by hooking directly into the SCADE main loop.
• Dynamic Configuration: A 3-region INI file was utilized to prevent recompilation requirements during field deployment.

Security mechanism: Upon detecting a missing or corrupted configuration file, the system automatically creates and saves default settings (localhost connection).

• Auto-Reconnection: Connection drops in industrial environments are inevitable; an autonomous auto-reconnect cycle was activated.
• Change Detection: A batch read and selective write strategy was implemented to optimize network traffic.

Architectural Decision: Since HMI hardware’s capability for simultaneous physical command processing is limited, outputs are evaluated in a sequential loop. This structural preference prevents unnecessary fieldbus traffic (network flooding).

• Thread-Safe Logging: Every event in critical systems must be logged securely.

Interlocking Scope

Example route: RT01: SN01E → TC01 → TC04 → TC02 → SN02E (Switch: Normal)

Safety Rule: Based on critical design principles, all signals not explicitly demanded by the system are configured to default to a restrictive state (red).

Results and Operational Takeaways

Quantitative Gain: (Potential values obtained during laboratory PoC tests)

Project Visuals

Related Links

 Source Code: Github/ansys-scade-modbus-integration-middleware 
Download TOK 2025 Paper: SCADE Modbus Paper Turkish (PDF)

Authors: Dora Demir¹, İbrahim Can Kolotoğlu², Muhammet Işık², Serhat Boynukalın³, Mehmet Turan Söylemez²
¹ ITU Electronics and Communication Eng. | ² ITU Control and Automation Eng. | ³ ITU Graduate School

This work was conducted at the ITU EEF Railway Systems Laboratory and published at the Turkish Automatic Control 2025 (TOK 2025) conference.