Hi, I wanted to share this small example model built using Architecture Design library (by DLR e.V. and Jasper Bussemaker, you can find it on Sysand.org).
It models a smart home hub product family and is structured into three files:
File
Description
SmartHomeLibrary.sysml
Reusable item, action, and part definitions for smart home components
SmartHomeDesignSpace.sysml
Architecture design space with function allocation, optional parts, and dependencies
SmartHomeArchitectures.sysml
Three architecture instances (basicHub, proHub, portableHub)
The example was intended to show how users could publish their own models/libraries as kpar files and how these could be embedded into projects using the sysand tool.
Hi Simas,
thank you for sharing this example.
I am very new to sysml v2 so please forgive me if my question is silly.
What is the use case of the model: comunicate with other people (dev team, stakeholders) or rather for machine readible configuration ?
How do you use the graphical representation of the model, when i generate it it seems to be more difficult grasp than the text itself.
This model is an example of how to model variants using the ArchitectureDesign library. The short answer to your question is: both, but at different layers of the model.
The component library (SmartHomeLibrary) defines reusable components with their actions and dependencies. In a real project, these would be owned by the subsystem teams (or dev teams if the system is software-defined), who define the characteristics, parameters, and interfaces of their components.
→ The library also captures machine-enforceable dependencies, which enables automations that could, for example, validate that any architecture including alexaModule also includes a WiFi radio.
The design space (SmartHomeDesignSpace) is where you define the rules that the product family needs to adhere to (e.g. the number of allowed components of a particular type, such as part zigbeeRadio : ZigbeeRadio [0..1]). The multiplicities here serve as both constraints and decision variables.
→ The purpose of this layer is both human-readable documentation of the product family rules and a machine-readable optimisation problem definition.
The architecture instances (basicHub, proHub, portableHub) are concrete configurations that select/deselect components from the design space. They subset smartHomeHub, meaning they’re validated against the design space.
→ These are useful for communicating features with stakeholders.
In terms of graphical representation, it is true that auto-generate diagrams can be harder to grasp than text. They become more useful when filtered to a specific view to address a particular concern (e.g. action flows or system hierarchy). We have recently added view support to Modeler and are working to improve its capabilities.
