This proof-of-concept MES application models traceability across a manufacturing and assembly workflow. It assigns a UUID to each component, uses role-based access control to separate responsibilities, applies FIFO-based inventory allocation, and records component-to-assembly relationships for later audit.

The application was developed around a representative UAV manufacturing scenario and tested as a software PoC. It has not been deployed in a production environment.

 Sectoral Scalability: Structured directly using 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 scenario below uses publicly known UAV platform names as representative examples. It does not reflect any real manufacturer’s process, data or configuration. The integration environments of autonomous platform products (TB2, AKINCI, etc.) within the defense sector mandate exceptionally strict 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. Relying solely on manual worksheets and disconnected ERP peripheral data matrices (often completely deviating from true FIFO constraints) 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 on role-based security boundaries and deterministic inventory allocations to effectively neutralize data-management risks.

Applied Methodology

Hardware (UUID) Serialization Process

Every fully manufactured physical component is ingested into the database environment formatted exclusively as a UUID. This explicit parameter 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 separated access roles were defined within the “Production” sector to physically enforce reliable duty segregation paradigms:

Automated Compatibility Isolation

Configuring a fail-safe framework, the network blocks aircraft assembly progressions if human data-input matrices or invalid 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)

overriding serial production degradation factors, the absolute oldest raw hardware components injected sequentially into the shop floor are prioritized 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

PoC Results — observed in functional testing of the application.

API Integration Architecture (ERP Readiness)

Operating OpenAPI 3.0 frameworks, OpenAPI documentation was generated as a basis for future ERP integration with enterprise systems such as SAP or Oracle. No SAP or Oracle integration has been implemented.

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

A standard C99-based middleware designed on the ANSYS SCADE Display platform, enabling HMI screens to communicate with field-level HIMA HiMatrix F35 safety PLCs via Modbus TCP/IP.

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: The generated SCADE application used in this setup provided no native Modbus interface. An external C middleware layer was therefore developed to exchange data with the HIMA controller while keeping the HMI logic separate from the communication layer. This is consistent with EN 50128 practice for separating application logic from communication.

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 used to prevent recompilation requirements during field deployment.

Fallback behaviour: If the configuration file is missing or invalid, the PoC writes a local default configuration for laboratory use. A production implementation should fail safely or require explicit operator confirmation.

• 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.