Generate architecture alternatives


One of the major challenges in the domain of Systems of Systems (SoS) is the dynamically changing architecture of the SoS. This means that the participating Constituent Systems (CSs) as well as their relations to each other change over time. This change can take place at different time scales. Long term changes might come along with new functions and capabilities of individual CSs and imply therefore also changes of the global (SoS) functions and capabilities.

In order to implement a change of the SoS architecture often one “big step” is not possible but several “small steps” are. These “small steps” represent reconfigurations of CS with a local rather than a global view to the SoS. CS engineers and/or managers are able to implement these changes locally without taking the entire SoS architecture into account. In DANSE this kind of reconfiguration of the SoS architecture is modeled using graph rewriting rules. These rules are based on architectural patterns and can be utilized to generate new architectures.

Figure 45 illustrates how the applications of “small steps” generate a set of (intermediate) architectures. As intermediate architectures only those are considered which are predecessors of the future architecture. This check is supported by the provided tool and is called “reachability check”. In case that the possible future architectures shall be explored the generation process can be used to generate those alternatives.


Figure 45: Investigate intermediate architectures

The drawback of this approach is that only the architecture and therefore only statically computable properties of the SoS can be taken into account. The consequence is that the generated intermediate architectures might violate contracts and/or only fulfill a subset of the goals. To investigate these properties the solution methods “perform joint simulation” (in combination with “perform statistical model checking”) and/or “perform timing analysis” and/or reviews of the architectures can be used. The coloring in Figure 45 indicates those results.

The approach for DANSE is therefore to generate a set of alternatives and verify the goals and contracts of the SoS as well as of the CSs by simulation, formal verification or review. Note that this supports the identification of unexpected emergent behavior on the simulation level.

The tooling consists of means to model architectural changes based on graph rewriting rules[1] in Rhapsody UPDM. This means are provided via the Rhapsody profile of the DANSE deliverable D6.5.1 “Extension of standard profiles for DANSE: Support for simulation-based evaluation of dynamic systems”. As generator GROOVE[2] is used and an automatically translation from UPDM to the GROOVE input format GXL and the feedback is under development within DANSE. This enables the user to define architectural changes in Rhapsody UPDM.

Initial Situation

As input for this solution method a UPDM model with DANSE extensions of the current SoS and if available a architecture or pattern for a future architecture of the SoS.

The CAE describes a fire service which uses TETRA and TETRAPOL communication devices. The future architecture is one with only LTE communication devise and a certain distribution of antennas. The question to be answered is how to evolve the individual fire stations and their managed fire brigades to a pure LTE communication topology. The entire evolution including all intermediate architectures must satisfy the global requirement that the first units must reach a house fire within a certain time bound.

Expected Result

The expected result is a set of contracts which restrict the evolution of the SoS in order to ensure that eventually the SoS has the future architecture and all intermediate architectures are valid and sufficiently fulfil the goals. The SoS model is enriched by more detailed contracts which direct the evolution in a way that the overall contract is fulfilled by all reachable architectures.

Note that the tooling could also be used to explore alternative architectures and therefore not result in such a set of contracts.

Required External Tools

·         IBM Rational Rhapsody 8.0

·         UPDM 2.0

·         GROOVE 4.8.7

Required DANSE Tools

·         DANSE Profile Extension for Rhapsody (D6.5.1) (Technical Solution No. 1 “UPDM improvements”)

·         Architecture Generation (Technical Solution No. 9 “Generation of architecture variants”)

·         Architectural Pattern Library (optional) (Technical Solution No. 6 “Reusable architectural and interaction patterns”)

·         Architecture Optimization (optional) (Technical Solution No. 10 “Architecture optimization techniques”)

·         GCSL language (Technical Solution No. 8 “GCSL: Goal and Contract Specification Language”) required by

·         RTANA – Timing analysis (optional) (Technical Solution No. 13 “Formal Verification”)

·         DESYRE (Technical Solution No. 11 “Joint simulation”) / PLASMA (Technical Solution No. 11 “Statistical Model Checking”) (optional)) requires:

o    FMU/FMI exporter

o    FMUs of CS behaviours

Figure 46: Tool Flow: Generate Architecture Alternatives


The activities of this solution method are shown in Figure 47: Activity Diagram: Generate Architecture Alternatives. The first steps cover the modelling and specification activities of the SoS depending on the creation type of the SoS. The first specific activity is to define the initial set of the evolution description in terms of rules. The next step is to check if this set of rules allows to evolve the current architecture into the future one or to explore a set of future architectures. Invalid or not satisfactory architectures are feedback as constraint rules and the process returns to the reachability check or the pure exploration with the new set of rules. If the intermediate architectures pass the analysis the set of rules is translated into contracts that specify the implementation of the change. In the following the individual activities are described in more detail.

Figure 47: Activity Diagram: Generate Architecture Alternatives

Define SoS Requirements in natural language

This step includes the initial requirement elicitation and negotiation activities. The result is a list of textual requirements.

Model SoS

The modelling activity covers the creation and the update of the SoS model using UPDM. The SoS model could be derived from observation of an existing SoS, the creation of an new model for an new SoS or an update of an previously developed SoS.

An SoS architecture is created/updated which contains CS representations that might be abstracted from detailed system model, learned by observing the real-world SoS or newly invented ones.

The result is a SoS model in the UPDM language.

Create/Import Pattern Library

Especially in the case of a new developed SoS an existing library from former project can be imported to the new project to gain from the architecture (and other) patterns during the development of the new SoS. In other cases where a SoS model is derived from an existing SoS, the library supports the improvement of the SoS.

The result of this step is a library of patterns which are relevant for the specific domain.

Formalize Requirements as Goals and Contracts

The formalization of natural requirements as goals or contracts requires at least the initial SoS model. The formalization process includes to translate the requirements into GCSL goals or contracts and the association to the CS which are responsible to fulfil the contracts. Global goals and contracts are associated to the SoS itself but the local ones to the CS.

As soon as the SoS model is extended with goals and contracts the verification of the SoS is possible if the model represents the properties of interest. Note that there is a direct relation between what is modelled and what is defined as goal or contract because the model represents the aspects of the SoS which are relevant and the goals and contracts define what is relevant.

The contract-based development approach is based on the idea to make the often implicit assumptions to the environment of an CS/SoS explicit and to decompose a higher level contract to several lower level ones. This relation depends in general on the architecture. Other benefits are that even in early development phases, where the CS are only roughly characterised, an interface definition is required which allows to check compatibility questions and the reuse of verification result at detailed  levels.

In the domain of SoS the architecture is evolving and therefore the reconfiguration of the SoS is part of its behaviour and implies the need to investigate those changes also in early development phases. The GCSL provides means (text-patterns) to specify under which conditions a CS/SoS has (not) to reconfigure in a certain way. This is defined as architecture pattern to cover not only individual architecture but sets of architectures.

The result of this step is a set of goals and contracts in a formal way with an unambiguous semantic specifying the system dynamics of CS/SoS as well as the reconfiguration of the SoS. The set of goals and contracts include statically contracts/goals which are evaluable without executing the behaviour. This could be the evaluation of a metric which only refers only to the architecture elements (e.g. sum of (weight of) CS) or a characterization of the architecture via an architecture pattern.

Mine future architecture

In case that the SoS architecture shall be improved the Pattern Library can be used to create a future architecture manually but guided. Without the library this can be performed completely manually.

The result is a characterization of a future architecture as architecture pattern.

Generate optimal architecture

In cases where a concise model of the SoS is available (e.g. from former development cycles) and compatible goals are annotated to this model, the future architecture can be generated by the “Architecture Optimization” DANSE tool. In this case the architecture is not only generated but also optimal according the goals specified.

The result is a characterization of a future architecture.

Derive constraint rules from statically contracts (optional)

The GCSL offers the ability to specify temporal relations between events or matching of architecture patterns by the SoS and CS architecture. In this context those contracts addressing the architecture of the SoS are used to reduce the number of generated architectures which must be investigated. The restrictive character of such contracts allows to formulate constraint rules which must not be applicable to the generated architectures. Each contract which characterizes the architecture is conceptually translatable into a constraint rule for the generation process. Using the DANSE extension profile these pattern can be modelled in Rhapsody (see tool documentation for details). This is a manual activity and therefore probably not realistically applicable because of complexity.

The resulting constraint rules are added to the set of rules.

Derive constraint rules from Patterns of the Pattern Library (optional)

The Pattern Library contains architectural pattern and properties of such pattern together with descriptions of the application domain and further documentation. This information can be used to derive constraint rules restricting the generation process in order to avoid architectures which match to pattern known to be invalid or poor with regard to a certain metric. In general the patterns in the library are positive characterizations and these need to be translated into restrictive pattern to be used as constraint rules. The modelling means provided via the DANSE extension profile allow to specify those constraint rules and the Pattern Library gives additional inputs.

The resulting constraint rules are added to the set of rules.

Derive constraint rule from future architecture (optional)

The future architecture provided by the “Architecture Optimization” DANSE tool can be translated into a quite detailed pattern. The manual or supported creation of a future architecture provides directly an architectural pattern. This pattern is used to characterize the termination condition of the generation process.

This termination pattern is also added to the set of rules but not as constraint rule. The reachability check requires this rule as target.

Define/Update transition rules representing local changes

Initially the set of rules is empty or only contains the future architecture. To complement the set of rules for each type of CS in the SoS all possible (ability and willing to change) reconfigurations should be added to the set even if it is not clear if this supports to converge to the desired future architecture.

The set of rules shall be iteratively updated by adding new local rules like mentioned before or by decomposing global rules into local ones. The difference between a global and local rule is that the global ones require a global view to the SoS and changes of more than one CS while the local ones represent changes initiated by individual CS with a local view only. Initially the current and the future architecture can be translated into a global rule describing one “big step” from the current to the global one. The decomposition of this global rule into local ones is the goal of this solution method.

At the end the set of rule shall contain all possible reconfigurations and all rules are local ones.

Translate intermediate architecture into constraint rule

If the architectural contracts have not been complete or one architecture violates a dynamic contract the generation process might generate an invalid architecture. To exclude such architectures from the evolution they are translated into constraint rules.

For architectures not satisfying the goals sufficiently the same method can be applied but in case of contradicting goals, none of the architectures might be allowed afterwards. To handle this, an iterative process is proposed where previously excluded valid architectures are allowed again if the reachability of the future architecture is not given.

Check reachability of future architecture (optional)

If a future architecture pattern is given, the reachability check can performed automatically based on the current architecture and the set of rules. The future architecture and a counter are used to terminate the generation process. The generation process generates (but not stored as UPDM SoS model) all intermediate architectures where the constraint rules are not applicable until the future architecture is reached or the threshold of the counter is exceeded.

Identify a shortest path to future architecture (optional)

If a future architecture pattern is given and reachability analysis has been performed one shortest path from the current to the future architecture is to be identified. This can be done by applying classical algorithms on the generated network of (intermediate) architectures.

Generate network of architectures

The result of this is a network of architectures as illustrated in Error! Reference source not found.. From the technological point of view it is similar to the reachability check. The counter is set to the length of one of the shortest paths derived from the reachability check and the intermediate architectures are stored as UPDM SoS models to be further investigated.

Select subset of architectures (optional)

Without an future architecture as goal for the reconfiguration of the SoS the engineer might want to investigate the possible architectures in order to find a good/optimal one. In cases where the generated network of architectures is quite large the engineer might want to select an appropriate subset probably based on the number of applied rules to the initial architecture or even randomly. A strict procedure cannot be defined for this selection.

The result is a list of generated architectures to be analysed.

Manual and Timing Analysis

The set of generated architectures might include architectures which violated contracts and goals which can be evaluated without simulation. One class of those contracts are timing contracts which can be analysed by the “Timing Analysis” DANSE tool which performs a formal verification based on timing properties and contracts. On the other hand an engineer might discover invalid or poor (in terms of the goals) architectures by inspecting them even without tool support. Those invalid/less promising architectures can be used to extend the constraint rules to reduce the number of generated/reachable architectures. To avoid the analysis of architectures which are only reachable via invalid ones these architectures are transformed into constraint rules and the generation process is initiated again.

The result is ether an invalid/poor architecture or a set of “promising” architectures.

Select architecture to investigate by simulation

From the set of “promising” architectures which passed the manual/formal verification sequentially one architecture is selected for simulation and statistical model checking.

Perform Simulation and Statistical Model Checking

The selected architecture is investigated by simulation and formal verification to identify dynamic properties which cannot be derived from the architecture only. Note that for the simulation also the simulation architecture as FMI and the simulation behaviours of the CSs as FMU are required.

If one of the architectures is invalid or poor, the architecture is translated into a constraint rule and a new set of architectures is generated. Note that the results for previously iterations are reusable if the new architectures are isomorph to the previous ones. Furthermore the investigated properties of these architectures might be feed back to the Pattern Library to enable reuse even in other SoS projects.

Translate local change rules and constraint rules into local contracts

One of the last steps is to decompose the set of rules into a set of contracts. These contracts should be decomposed to local contracts to enable local verification/implementation of existing/new CSs. The GCSL P3 “always” pattern can be used to define textual representations of architectural pattern as required for this transformation.

Define synchronization between CSs as contracts

In general it is not possible to decompose the entire set of rules into local ones because global information might be required. To enable the convergence of an SoS to the future architecture a set of synchronization points not only for the CSs but for the CS engineers and managers must be established. This plan must be agreed by all parties and the exchange of how and why synchronization is required can be illustrated by the graphical representations already used to describe architectural changes. If a plan is agreed it should be decomposed into contracts to ensure that responsibilities and the flows of information are clearly defined.


The main limitation is that only the architecture and none of the behaviour can be taken into account by the technology itself. The consequence is that this method depends on the analysis methods

  • “Perform joint simulation”/”Perform statistical model checking”,
  • “Perform timing analysis” (formal verification) or
  • manual review.

Another technical drawback is the probably high number (up to infinity) of generated architectures. This aspect is addressed by

·         generating only non-isomorph architectures (reduces the number of “similar” architectures),

·         introducing counters in the generation process (if the number of rule application is finite the number of architectures is as well)

·         restricting the generation process via constraint rules,

·         enabling the user to select candidates for the analysis and

·         feedback of analysis results and existing specifications (GCSL Contracts) as constraint rules to the generation process.

Follow-up Solution Methods

The method is to be applied in the “Analyse possible architecture changes” and/or “Influence and implement changes” phase of the life-cycle the next phase is the “Constituent System Engineering” phase.

Given the limitations, it is natural to use Generate Optimized Architectures in conjunction with Apply Architecture Patterns and Generate Architecture Alternatives as alternative methods to explore architecture variations.  Each of the three methods offers a different approach with different benefits and limitations

[1] E.g.: Barbara König. Analysis and Verification of Systems with Dynamically Evolving Structure. PhD dissertation. Universität Stuttgart, 2004. Or: G. Rozenberg, editor. Handbook of Graph Grammars and Computing by Graph Transformations, Volume 1: Foundations. World Scientific, 1997.

[2]E.g.: Rensink, A. (2004) The GROOVE Simulator: A Tool for State Space Generation. In: Applications of Graph Transformations with Industrial Relevance (AGTIVE). pp. 479-485. Lecture Notes in Computer Science 3062. Springer Verlag. ISSN 0302-9743 ISBN 978-3-540-22120-3

or visit

Home About Technical Approach Generate architecture alternatives