MBSE Context Boundaries for Secure Customer-Supplier Collaboration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional model-based systems engineering frameworks fail to account for the diverse interests and intellectual property concerns of collaborating parties, leading to challenges in sharing structured system models while maintaining confidentiality of sensitive information.
Innovation Solution
A method for collaborative design in model-based systems engineering that allows parties to delineate context boundaries, separate and synchronize model packages, and maintain confidentiality through the use of context boundary blocks and interface specifications, enabling secure information exchange between customers and suppliers.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If structured system models are shared between collaborating parties, then collaborative design capability is improved, but confidentiality of sensitive information deteriorates
Solution Approach 1:
The system model is segmented into multiple packages with different access permissions. Context boundary blocks are separated into public packages (accessible to all collaborators) and private packages (accessible only to specific parties). This segmentation allows collaborative design on shared interfaces while protecting sensitive internal implementations through selective information hiding.
Solution Approach 2:
Context boundary blocks serve as intermediaries between different collaborating parties. These blocks define standardized interfaces that mediate interactions between public and private portions of the system. Collaborators interact through these boundary blocks without direct access to each other's private model elements, enabling secure information exchange.
2Loss of information
If context boundaries are defined to protect sensitive information, then confidentiality is improved, but device complexity deteriorates
Solution Approach 1:
Context boundary blocks serve multiple functions simultaneously: they define system boundaries, specify interaction interfaces, control access permissions, and manage synchronization between collaborators. This multi-functionality reduces the need for separate mechanisms for each concern, thereby limiting the increase in model complexity while achieving confidentiality protection.
Solution Approach 2:
The system employs dynamic access control where package visibility and editability change based on the user's role and the collaboration context. Context boundary blocks can transition between different access states (read-only, editable, hidden) without requiring permanent structural changes to the model, allowing flexible confidentiality management with minimal complexity overhead.
3Loss of information
If model packages are separated for confidentiality, then information security is improved, but synchronization difficulty deteriorates
Solution Approach 1:
The system implements feedback mechanisms where changes to context boundary blocks trigger automatic notifications and synchronization protocols. When a collaborator modifies a boundary block interface, the system provides feedback to other collaborators about the nature of the change, enabling them to update their local copies accordingly. This feedback loop maintains synchronization without requiring continuous manual coordination.
Solution Approach 2:
Synchronization rules and access permissions are predefined and configured in advance for each package and context boundary block. Collaboration agreements about interface modification protocols are established before the collaborative design begins. This preliminary configuration reduces the complexity of real-time synchronization by having predetermined rules ready to handle various change scenarios.
Data Source
AI summary
A method for collaborative design of a system of interest (SoI) in a model-based systems engineering (MBSE) framework models the system into an artifact including customer-owned and supplier-owned portions. The customer system identifies a collaborative portion within the artifact, shared by both customer and supplier, wherein data exchanges and modifications to the SoI will take place, the collaborative portion defined by a context boundary. The customer and supplier package their respective shareable portions of the SoI into bundles including the customer-initiated collaborative portion and a supplier-owned copy. Further modifications to the SoI may be implemented via cadenced synchronization of the customer-owned and supplier-owned copies of the collaborative portion to exchange, accept, and propagate successive changes initiated by either party.