1. Dmitrii Kirov Avatar Dmitrii Kirov
  2. Untitled project
  3. ArchEx

Wiki

Clone wiki

ArchEx / Requirement patterns

View History

A pattern has a short name that intuitively reflects the associated requirement, close to a natural language expression, while still preserving its formal semantics. Each pattern is used to automatically generate MILP constraints over the input arguments, operating on corresponding subsets of decision variables. For more details please refer to [1].

Patterns currently provided by ArchEx are summarized below. They are grouped by corresponding requirement classes (e.g., interconnection, reliability). For each pattern we provide its name, description in English, list of arguments and an example.

Notes

  • Variables used as pattern arguments can be of two data types: char (for arguments that represent component types and subtypes) and numeric (for arguments representing a value, e.g., max/min number of a certain quantity)
  • Arguments marked with prime (') are optional and can be omitted. When used, they allow for more flexible requirement specification, i.e., a constraint created from such pattern can affect only a certain subset of components of the same type (e.g., a requirement is valid only for high voltage generators among all generators of the system).
  • Component type arguments (T) can be enriched with tags for more flexible classification. Tags are used for sub-classifying components having the same type (and, possibly, subtype) for a specific problem. Type and subtype are library attributes, while tags are not. For example, "Generator Left" expresses all generators on the left part of the aircraft. These generators can still be of "High voltage" or "Low voltage" subtype in the library.

Generic patterns

Patterns from this group can be applied to different classes of requirements, which reflects their generic nature. For instance, they can be used to require a certain amount of components in the final configuration or certain amount of paths between some component types. This can be essential for different kinds of requirements, e.g., reliability, timing and so on.

at_least_N_components(T,S',N)

There must be at least N component(s) of type T with subtype S.

Arguments:

  • T: component type (e.g., "Generator")
  • S: component subtype (e.g., "High voltage") - optional
  • N: required min number of components

######Example: There must be at least three high voltage generators => There must be at least 3 components of type "Generator" with subtype "High Voltage" => at_least_N_components(Generator,High voltage,3)

at_most_N_components(T,S',N)

There must be at most N component(s) of type T with subtype S.

Arguments:

  • T: component type (e.g., "Generator")
  • S: component subtype (e.g., "High voltage") - optional
  • N: required max number of components

######Example: There must be at most one low voltage rectifier => There must be at most 1 component of type "Rectifier" with subtype "Low Voltage" => at_most_N_components(Rectifier,Low voltage,1)

exactly_N_components(T,S',N)

There must be exactly N component(s) of type T with subtype S.

Arguments:

  • T: component type (e.g., "Generator")
  • S: component subtype (e.g., "High voltage") - optional
  • N: required exact number of components

######Example: There must be exactly two low voltage buses => There must be exactly 2 components of type "Bus" with subtype "Low Voltage" => exactly_N_components(Bus,Low voltage,2)

Interconnection patterns

at_least_N_connections(T1,T2,N)

Every component of type T1 must be connected to at least N components of type T2. Component types T1 and T2 must be adjacent in the functional flow (neighbouring).

Arguments:

  • T1: first component type (e.g., "Source")
  • T2: second component type (e.g., "Conveyor")
  • N: required min number of paths

######Example: Every source must be connected to at least one conveyor => Every component of type "Source" must have at least 1 connection to components of type "Conveyor" => at_least_N_connections(Source,Conveyor,1)

at_most_N_connections(T1,T2,N)

Every component of type T1 must be connected to at most N components of type T2. Component types T1 and T2 must be adjacent in the functional flow (neighbouring).

Arguments:

  • T1: first component type (e.g., "Source")
  • T2: second component type (e.g., "Conveyor")
  • N: required min number of paths

######Example: Every source must be connected to at most one conveyor => Every component of type "Source" must have at most 1 connection to components of type "Conveyor" => at_most_N_connections(Source,Conveyor,1)

exactly_N_connections(T1,T2,N)

Every component of type T1 must be connected to exactly N components of type T2. Component types T1 and T2 must be adjacent in the functional flow (neighbouring).

Arguments:

  • T1: first component type (e.g., "Load")
  • T2: second component type (e.g., "DC bus")
  • N: required min number of paths

######Example: Every load must be connected to exactly one DC bus => Every component of type "Load" must have exactly 1 connection to components of type "DC bus" => exactly_N_connections(Load,DCBus,1)

exactly_N_connections_if_used(T1,T2,N)

Every component of type T1, that is used (instantiated) must be connected to exactly N components of type T2. Component types T1 and T2 must be adjacent in the functional flow (neighbouring). The constraint applies only to those components, that are used in the architecture (if component is not used, i.e., is not connected to any other component, then this constraint does not apply to it).

Arguments:

  • T1: first component type (e.g., "Generator")
  • T2: second component type (e.g., "AC bus")
  • N: required min number of paths

######Example: If a generator from the middle part of the aircraft is used then it must be connected to exactly one AC bus from the left part. => Every component of type "Generator Middle" that is used must be connected to exactly 1 component of type "ACBus Left" => exactly_N_connections_if_used(Generator Middle,ACBus Left,1)

at_least_N_paths(T1,T2,N)

Every component of type T1 must have at least N paths to components of type T2. One path here is a single path on a graph from component of T1 to some component of T2. That is, if component of T1 has one single path to one component of T2 and another single path to another component of T2, and N = 2, then the requirement is satisfied. Length of paths (number of edges/hops) does not matter. Component types T1 and T2 do not have to be adjacent in the functional flow.

Arguments:

  • T1: source component type (e.g., "Load")
  • T2: destination component type (e.g., "Generator")
  • N: required min number of paths

######Example: Every load must have at least 3 paths to generators => Every component of type "Load" must have at least 3 paths to components of type "Generator" => at_least_N_paths(Load,Generator,3)

at_most_N_paths(T1,T2,N)

Every component of type T1 must have at most N paths to components of type T2.

Arguments:

  • T1: source component type (e.g., "Load")
  • T2: destination component type (e.g., "Generator")
  • N: required min number of paths

######Example: Every source must have at most 1 path to sink => Every component of type "Source" must have at most 1 paths to components of type "Sink" => at_most_N_paths(Source,Sink,1)

exactly_N_paths(T1,T2,N)

Every component of type T1 must have exactly N paths to components of type T2.

Arguments:

  • T1: source component type (e.g., "Load")
  • T2: destination component type (e.g., "Generator")
  • N: required min number of paths

######Example: Every bus must have exactly 3 paths to generators => Every component of type "Bus" must have exactly 3 paths to components of type "Generator" => exactly_N_paths(Bus,Generator,3)

in_conn_implies_out_conn(T_in,T,T_out)

Similar patterns:

  • no_in_conn_implies_out_conn(T_in,T,T_out)
  • in_conn_implies_no_out_conn(T_in,T,T_out)
  • no_in_conn_implies_no_out_conn(T_in,T,T_out)

Arguments:

  • T_in:
  • T:
  • T_out:

out_conn_implies_in_conn(T_out,T,T_in)

Similar patterns:

  • no_out_conn_implies_in_conn(T_out,T,T_in)
  • out_conn_implies_no_in_conn(T_out,T,T_in)
  • no_out_conn_implies_no_in_conn(T_out,T,T_in)

Arguments:

  • T_out:
  • T:
  • T_in:

cannot_connect(T1,S1',T2,S2')

Arguments:

  • T1:
  • S1:
  • T2:
  • S2:

no_self_loops(T)

Arguments:

  • T:

bidirectional connection(T1,T2)

Similar patterns:

  • no_bidirectional connection(T1,T2)

Arguments:

  • T1:
  • T2:

Reliability patterns

min_redundant_components(T,N)

max_failprob_of_connection(T1,T2,N)

Workload patterns

flow_balance(T,S')

no_overloads(T,S')

Timing patterns

max_total_idle_rate(T,N)

Mapping patterns

at_most_one_mapping(T)

if_used_then_mapped(T)

incoming_then_mapped_to(T_in,T,S)

Updated