Design Space
adore.api.schema.adore_schema.Project
Project is the top-level container and contains three main items:
- The design space defines the space of possible architectures, together with all choices to be taken.
- Design problems turn architecture decisions and Quantities Of Interest into design optimization problems, optionally reducing the design space by fixing design variables.
- Architectures are instantiations of the design space, where decisions taken (and design variables if linked to a design problem) are tracked. Quantities Of Interest (and optionally objectives/constraints) have their values set if the performance of the architecture has been evaluated.
Design Space
adore.api.schema.adore_schema.DesignSpace
DesignSpace defines the system architecture design space, which implicitly contains all possible system architectures. Information about architecture choices is also stored here.
context
context: SystemContext = context
This is the system context, or external environment. It defines elements (functions, components, etc.) that are to be seen as being external to the system being designed. They could for example be external value functions (i.e. the function that delivers the final value to the stakeholders), or components that fulfill some function from the system but are external to the system (like some service provided by an external party).
decisions
decisions: List[Decision] = decisions
Contains all architecture choices derived from the architecture design space. Usually derived using the ADSG (Architecture Design Space Graph).
structural_constraints
structural_constraints: List[StructuralConstraint] = structural_constraints
Contains structural constraints.
system
system: System = system
This is the system that is to be designed. It contains all elements contained in the system, and can contain additional (sub-)systems itself.
adore.api.schema.adore_schema.System
This is the system that is to be designed. It contains all elements contained in the system, and can contain additional (sub-)systems itself.
A system that contains architecture elements, and optionally additional system. Systems can be instantiated multiple times.
is_conditional
Whether or not this element exists conditionally (i.e. behind some architectural choice).
is_included
Whether or not this element is included in the design space graph and can be included in architecture instances.
n_inst
List of number of possible system instances. For example [1, 2] means 1 or 2 instances are possible, while [1, 3] means either 1 or 3 instances are possible, etc.
adore.api.schema.adore_schema.SystemContext
This is the system context, or external environment. It defines elements (functions, components, etc.) that are to be seen as being external to the system being designed. They could for example be external value functions (i.e. the function that delivers the final value to the stakeholders), or components that fulfill some function from the system but are external to the system (like some service provided by an external party).
is_conditional
Whether or not this element exists conditionally (i.e. behind some architectural choice).
is_included
Whether or not this element is included in the design space graph and can be included in architecture instances.
System Elements
adore.api.schema.adore_schema.Function
Represents a function to be fulfilled. If functions are not derived (i.e. not needed by any other element), they can be considered external, which means that they will always be present in any derived architecture, since these functions are the ones that provide the external value to the stakeholders.
Functions can be classified as solution-neutral or solution-specific. Normally, functions are solution-specific, but solution-neutral functions can be used to declare that these functions are not biased towards a possible solution, but rather represents the underlying function to be delivered by the system.
boundary_function
Define the function as a boundary function or not. If not set, automatically determined based on whether the function is derived by any component (if not, it is used as a boundary function).
is_conditional
Whether or not this element exists conditionally (i.e. behind some architectural choice).
is_included
Whether or not this element is included in the design space graph and can be included in architecture instances.
adore.api.schema.adore_schema.FunctionType
adore.api.schema.adore_schema.Component
Represents a component that can be part of the (physical) architecture. A component fulfills one or more functions, and can need (derive) one or more additional functions.
Components are involved in architecture choices at three levels: 1. Which component to use for fulfilling a function. 2. Characterization through component instantiation and component attribute values. 3. Component connections through ports.
input_ports
input_ports: List[PortConnection] = input_ports
Port connections defined as input: i.e. they need an incoming connection.
instance_attributes
instance_attributes: List[Attribute] = instance_attributes
Attributes of the component instances: per instance one attribute and the associated value choice will be assigned.
instance_qois
instance_qois: List[Qoi] = instance_qois
Quantities Of Interest assigned to the component instances (one per component instance).
is_conditional
Whether or not this element exists conditionally (i.e. behind some architectural choice).
is_included
Whether or not this element is included in the design space graph and can be included in architecture instances.
n_inst
List of number of possible component instances. For example [1, 2] means 1 or 2 instances are possible, while [1, 3] means either 1 or 3 instances are possible, etc.
output_ports
output_ports: List[PortConnection] = output_ports
Port connections defined as output: i.e. they can provide outgoing connections.
adore.api.schema.adore_schema.Qoi
Represents a Quantity Of Interest. QOIs are associated with functions or components, and specify something about what quantities are relevant in evaluating the system.
When translating the architecture design problem to an optimization problem, QOIs can be interpreted in multiple different ways: 1. Objective: possible if the QOI is present in all derived architectures. 2. Constraint: possible if a reference value is given. 3. Metric: generic output metric that needs to be tracked but otherwise has no special meaning to the design problem. 4. Design variable: possible if either bounds (for continuous) or options (for discrete) are given.
It is possible that multiple interpretations are possible, which is why a QOI type can be specified as well.
bounds
Lower and upper bound if used as a continuous design variable.
is_conditional
Whether or not this element exists conditionally (i.e. behind some architectural choice).
is_included
Whether or not this element is included in the design space graph and can be included in architecture instances.
options
List of options to choose from if used as a discrete design variable.
pos_better
Whether or not a positive (i.e. higher) number should be interpreted as better. Relevant for objectives and constraints. For an objective, positive being better gives a maximization target (negative better a minimization), while for constraints positive better prescribes the performance to be higher than or equal to the provided reference value.
units
Optional units that the numerical value is specified in. Should be compatible with Python's pint library.
adore.api.schema.adore_schema.QOIType
adore.api.schema.adore_schema.Attribute
Represents an attribute of a component or component instance. Attributes are assigned to attribute values using assignment choices (the same mechanism as for port connections), which allows for implementing more complex behavior than just choosing one value from multiple value options.
group_per_component
Whether to group connections from attributes to attribute values for all attributes per component or not. If grouped, it means that the order of which attribute connects to which attribute value does not matter.
is_conditional
Whether or not this element exists conditionally (i.e. behind some architectural choice).
is_included
Whether or not this element is included in the design space graph and can be included in architecture instances.
adore.api.schema.adore_schema.AttributeValue
Represents a possible value to be assigned to an attribute.
is_conditional
Whether or not this element exists conditionally (i.e. behind some architectural choice).
is_included
Whether or not this element is included in the design space graph and can be included in architecture instances.
adore.api.schema.adore_schema.PortConnection
Represents a port connection of a component instance to/from a port. Depending on whether it is assigned to the input or output ports of the component, it is treated as an input or output port. Connections are always made from output port connections to input port connections.
grouping
grouping: Optional[PortGroupingType] = grouping
Whether (and how) port connections are grouped. Grouped port connections mean that the order in which the connections are assigned to the corresponding port instances is not relevant for the choices at hand.
is_conditional
Whether or not this element exists conditionally (i.e. behind some architectural choice).
is_included
Whether or not this element is included in the design space graph and can be included in architecture instances.
n_inst
List of number of possible port instances per component instance. For example [1, 2] means 1 or 2 instances are possible, while [1, 3] means either 1 or 3 instances are possible, etc.
adore.api.schema.adore_schema.PortGroupingType
Whether (and how) port connections are grouped. Grouped port connections mean that the order in which the connections are assigned to the corresponding port instances is not relevant for the choices at hand.
adore.api.schema.adore_schema.ConnSpec
Specifies the connection behavior of connection sources and targets (e.g. port connections or attributes). It specifies whether repeated connections between the same sources and targets are allowed, and how many connections are possible in total.
Either nSpecific or nRangeMin should be specified.
n_range_max
Defines an upper bound (inclusive) of the number of connections allowed. If not specified and nRangeMin is specified, there is no upper bound on the amount of connections (i.e. infinite).
n_range_min
Defines a lower bound (inclusive) of the number of connections allowed.
n_specific
A list of specific number of connections allowed. For example [0, 1] means that either zero or one connection is allowed, while [1] means exactly one, and [1, 2, 3] means either 1, 2, or 3 connections are allowed, etc.
adore.api.schema.adore_schema.Port
Represents a port using which connections between component port instances can be made.
is_conditional
Whether or not this element exists conditionally (i.e. behind some architectural choice).
is_included
Whether or not this element is included in the design space graph and can be included in architecture instances.
adore.api.schema.adore_schema.Concept
Represents a notional mapping between a solution-neutral function and a solution-specific function. Can be helpful for distinguishing between alternative concepts in the architecture design space.
is_conditional
Whether or not this element exists conditionally (i.e. behind some architectural choice).
is_included
Whether or not this element is included in the design space graph and can be included in architecture instances.
adore.api.schema.adore_schema.Decomposition
Represents a decomposition of one function into multiple other functions. In principle the zoomed functions represent the same functionality as the emerged function, which is also where the terms zooming and emerging come from: applying the decomposition can be seen as zooming-in at the function, while the reverse can be seen as one function emerging from multiple lower-level functions.
is_conditional
Whether or not this element exists conditionally (i.e. behind some architectural choice).
is_included
Whether or not this element is included in the design space graph and can be included in architecture instances.
adore.api.schema.adore_schema.NonFulfillment
Represents the explicit non-fulfillment of a function. Can be used to represent choices on whether to include some additional technology or not.
is_conditional
Whether or not this element exists conditionally (i.e. behind some architectural choice).
is_included
Whether or not this element is included in the design space graph and can be included in architecture instances.
adore.api.schema.adore_schema.MultiFulfillment
Represents fulfillment of multiple (1+) functions by multiple (1+) elements simultaneously.
is_conditional
Whether or not this element exists conditionally (i.e. behind some architectural choice).
is_included
Whether or not this element is included in the design space graph and can be included in architecture instances.
adore.api.schema.adore_schema.StructuralConstraint
Represents an architecture structural constraint. Constrains some behavior between two or more design space elements.
element_ids
Design space elements involved in the structural constraint.
adore.api.schema.adore_schema.StructuralConstraintType
Structural constraint types:
- Incompatibility: determines that of the linked elements, only one can exist in an architecture instance (i.e. they are incompatible with each other).
- Linked choice: choices will have the same value
- Permutation choice: choices will have a permutation of the possible values
- Unordered choices: choices will have any combination of the values except permutations
- Unordered non-replacing choices: same as previous, except same values cannot be selected twice
Derived Elements
adore.api.schema.adore_schema.Issue
Represents an issue with the design space, as derived by trying to construct the ADORE graph. Helpful for providing feedback to the user editing the design space.
adore.api.schema.adore_schema.IssueType
Issue types:
- Empty design space: the design space is empty and therefore cannot be interpreted as a graph.
- No functions/components: at least one function and component must be defined.
- Component must fulfill: a component (also includes concepts and decompositions) must fulfill at least one function.
- Function not fulfilled: functions must be fulfilled by at least one component.
- Unconnectable port: port connections cannot be fulfilled.
- Infeasible incompatibility: an incompatibility constraint is defined between two elements that always exist together, which makes the constraint infeasible.
- Impossible choice constraint: there are too many choices for the amount of non-replacing options.
- Unknown QOI units: units of a QOI cannot be parsed.
adore.api.schema.adore_schema.Decision
Represents an architecture choice. Can either be of selection type (i.e. choose one of the available options) or connection (called 'permutation' in the data model, the old name) type (i.e. connect source nodes to target nodes according to some rules). Decisions are automatically defined based on the structure of the design space using the ADSG (Architecture Design Space Graph).
source_ref_element_ids
References to design space elements where the choice originates from.
target_ref_element_ids
References to design space elements targeted by the choice.
adore.api.schema.adore_schema.DecisionType
adore.api.schema.adore_schema.DecisionOperation
adore.api.schema.adore_schema.Statistics
Stores statistics regarding encoding of the design space, design problems, or design choices
distance_correlation
Number between -1 and 1 representing how much a difference in encoded design vector corresponds to a difference in connection pattern
imputation_ratio
Ratio of (nCombinatorial*nExistence)/(nValid): lower is better
imputation_ratio_comb
Ratio of (nCombinatorial*nExistence)/(nValid), only discrete design variables: lower is better
imputation_ratio_cont
Ratio of nDimCont/nDimContMean, only continuous design variables: lower is better
information_index
Number between 0 and 1, where 0 represents one design variable with nValid options, and 1 represents multiple design variables with 2 options each: higher is better
n_declared
Number of declared discrete design points in the design space (cumulative product of all choice options)
n_dim_cont_mean
Mean continuous dimensions that are active over all discrete design points
n_existence
Number of different existence patterns that this (sub-)problem can be active for
Types
adore.api.schema.adore_schema_defs.Element
Element = Union[BaseSystem, Function, Concept, Decomposition, Component, Qoi, Port, PortConnection, Attribute, NonFulfillment, MultiFulfillment]
adore.api.schema.adore_schema_defs.WalkElement
WalkElement = Union[Element, DesignSpace, Issue, Decision, StructuralConstraint]
adore.api.schema.adore_schema_defs.Object
Object = Union[Element, ArchElement, DesignVar, ArchDesignVar, Objective, Constraint, Metric, Decision, ArchDecision, ArchObjective, ArchConstraint, Architecture, DesignProblem, ExternalElement, ExternalDatabase]