The RA employs a set of standardized design patterns to ensure that all components, whether internal or vendor-provided, adhere to the core principles of the Aero-Factory.
These architectural patterns are presented with brief explanations for exemplary purposes and do not constitute a full technical specification.
The entire Aero-Factory ecosystem operates on an asynchronous event-driven model. Every state change, from a sensor variance on the floor to a high-level orchestration command, is treated as an Event. The Vortex Data Broker ensures these events are broadcasted to authorized subscribers across all layers, enabling the system to react in real-time to the dynamic conditions of the production line without rigid, monolithic dependencies.
This pattern is mandatory for Aero-MES and all internally deployed, third-party Manufacturing SaaS systems. By decoupling logic into independent microservices, the Aero-Factory gains infinite scalability and resilience.
Instead of a single, monolithic model, Aero-Factory enforces a strategic separation of the Digital Twin into two distinct environments:
This pattern manages the lifecycle of data through two primary states:
Zero-Trust is enforced as a per-packet mandate at the L2/L3.5 boundary. No entity is trusted by default. Every command must pass DPI Lite validation by the Vortex Edge's Traffic Orchestrator (L2) to ensure operational safety, and every cross-zone data flow must pass Full DPI at the Vortex Proxy (L3.5) to ensure cybersecurity hygiene.
The RA defines three specific zones of integration to ensure that third-party systems interact with the Aero-Factory in a secure and controlled manner. The Legal Status of the data is determined by the Convention of Origin (the specific Vortex Data Broker instance the vendor connects to).
Governs Vendor Apps interacting directly with hardware, typically via M-2-M interface. Even for "monolithic" or out-of-the-box solutions, the Traffic Orchestrator in the Vortex Edge intercepts all flows. Communication succeeds only after DPI Lite approval, ensuring the "No Secrets" fork is executed and the command is logged as a B2MML OpRequest fragment as well (forked delivery).
This is the On-Premise integration for vendors requiring high-fidelity data. Vendor applications at this layer interact with the Vortex Site Hub and have exclusive access to Raw Data for high-speed local processing (e.g., Engine Trend Monitoring). Data is delivered in UDS Envelopes containing B2MML and Vortex CDM payloads. By convention, all data at this layer is Raw, containing unmasked private metadata and internal identifiers.
The Global/Cloud integration for long-term oversight. Vendor applications interact with the Vortex Central Hub and access only Refined Data. The UDS Envelopes here contain sanitized B2MML and Vortex CDM objects that have passed the L5 Refinement Gate (f.e., GDPR masking and de-identification). This provides a secure, corporate-approved view of performance and maintenance.
Multi-Zone Compliance: A single vendor may deploy components across all three zones. However, strict isolation is maintained by the Vortex Data Broker topology. By convention, Raw data (private/high-fidelity) is exclusively available at the Site Hub or lower (L4-) for local processing, whereas only Refined data (sanitized/public) is published at the Central Hub (L5) for global monitoring and cloud services.
More information about UDS Envelopes, B2MML and Vortex CDM is available in Data Model section.
AI/ML tools must interface with the Aero-Lakehouse at L5 using standardized cloud-provider integration patterns. These tools primarily consume Refined Data via the L5 Monitoring pattern to ensure model quality.
The architecture is Cloud-Agnostic, supporting "Plug-and-Play" connectivity with major hyperscalers. Any predictive command generated by an AI model must descend as a new event through the Vortex Data Broker, passing through L3.5 (Full DPI) and L2 (DPI Lite) before execution, maintaining the closed-loop integrity of the system.